The New “Unified Star Schema” Paradigm in Analytics Data Modeling Review | by Andriy Zabavskyy | Towards Data Science

Recently I accidentally came across the new book of Bill Inmon and Francesco Puppini called “Unified Star Schema” (will refer to it USS downstream). Having a new book in 2020 from the father of data warehousing definitely grabbed my attention, I bought it and read it in the following 3 days with lots of enthusiasm. It turned out the author of the concept is Francesco Puppini and Bill Inmon is a supporter and promoter of it, but it doesn’t really diminish the value of a new approach for modeling and organizing the data.
In the beginning, I was really skeptical. Replacement of a traditional dimensional model, proved by decades didn’t make me feel well about it. But the book opened to me a new perspective of data model view. Now I believe it could be treated as not a replacement of traditional dimensional modeling (despite the fact the author claims it to be), but a good enrichment of it. So let’s review it briefly.
On the high level, the author proposes the ingeniously simple approach for managing connections (relationships) between entities in the analytics database: instead of having the net of interrelationships, introduce the super switchboard and manage all the connections via it:
If we translate this statement into the data warehouse data model, it would mean replacement of the galaxy schema (set of star schemas joint via conformed dimensions) by one super star where all the tables (both fact and dimensions) are joined via one big auxiliary table called Bridge (named by author) or Puppini Bridge(named by Inmon; I like it more, so will use it :) like on the picture below:
The Puppini Bridge is used strictly to join the tables between each other, it doesn’t have a business value, and is suggested to be hidden from the end customers.
How the magic table is being built? It’s not a trivial thing so let’s take a look.
There is a prerequisite: each table in the data warehouse should have a primary key built on a single column. It is recommended to follow the naming convention: use the_KEY_ prefix followed by the table name.
The Puppini Bridge table is a matrix-like table where
Columns — list of primary keys of each data warehouse table (fact or dimension) plus one extra column called Stage . So the number of columns equal to the number of tables in the data warehouse (dimensions and facts) plus one.
Rows — a result of union all operation of all data warehouse tables carrying only the key columns. So the number of rows in a Bridge table is a sum of all records in the data warehouse (fact and dimensions).
To fill the Bridge table we would need to split the process into stages, where each stage — loading data from one of the data warehouse tables. For each table, we need to set the Stage column value equal to the data warehouse table name and load:
The primary key of the data warehouse table
All foreign keys to other data warehouse table; direct foreign keys, and derived ones
For the example above the initial relationships between fact and dimension tables would lead to the following Puppini Bridge fulfillment (dark red cells contain derived foreign keys):
Having such an intermediate bridge table we could join any two Data warehouse tables using the proper key columns. For example, to group Sales Orders and Sales Forecast Amounts by Product Category and combine the results we would need to do a left join with Puppini Bridge table like that:
select pc.CategoryName,       sum(so.SalesAmount),       sum(sf.ForecastedAmount)  from _PuppiniBridge pb       left join SalesOrders so            on pb._KEY_SalesOrders = so._KEY_SalesOrders       left join SalesForecast sf            on pb._KEY_SalesForecast = sf._KEY_SalesForecast       left join ProductCategory pc           on pc._KEY_ProductCategory = pc._KEY_ProductCategory group by       pc.CategoryName
The whole “Unified Star Schema” book is around the benefits of USS in Self Service BI. By self-service BI it is meant the possibility of exploring and discovering the data in any modern BI platform, such as Tableau, Qlik View/Qlik Sense, Tibco SpotFire, MS PowerBI, by data analysts and business representatives.
The galaxy schema always contains the loop connections (unless it is not a trivial one) which leads to ambiguity. That is why the BI platform limits the possibilities for table connections between each other to avoid loops, which leads to the limitations of the data exploration possibilities or the necessity of workarounds on the data model side.
Converting the galaxy schema into the USS, which is a simple star schema eliminates the set of constraints put by BI platforms.
The USS schema helps to resolve the following challenges:
Loops
The Fan Trap
the Chasm Trap
Non-conformed granularity joins
The detailed explanation of these challenges along with detailed descriptions and examples you could find in the book.
Besides the Self Service BI there are also other aspects of Data Warehouse data consumption scenarios, so let’s try to look at the USS from another point of view.
My main concern related to the USS is the efficiency of Join operations and the scalability of the approach in general.
Since the Puppini Bridge table is a superset of all data warehouse tables including the fact tables, it is going to be a large table. So in case of querying at least one fact table, we would have always a join between two large tables (bridge with a fact table) which is always a challenge for the relational database. We could think of merge join for optimizing that, but most probably it won’t be possible since the ordering for one fact table won’t work for another fact table, etc.
A similar challenge is related to the data distribution for cluster deployments. If we distribute a large fact table according to a certain rule, we won’t be able to apply the same rule for the Puppini Bridge table. Even though we could do that for one fact table, we won’t be able to do that for another fact table. So this leads to the same concern of joining efficiency between _Puppini_Bridge and other large fact table on the database clusters.
The schema extension is always a pretty challenging aspect of a Data Warehouse solution.
When we introduce a new subject area into the data warehouse or a new set of business processes, in a traditional way — we introduce a new set of tables (a new set of star schemas).
In the case of USS we would need besides that perform really heavy lifting operations on the Bridge table:
alter it by adding a list of new columns with proper key columns
backfill it with proper connection information
So, in the case of a large data warehouse, it tends to be a really heavy operation.
If to step out of Self Service BI and think of predefined reports or data scientist’s data exploration activities, it is more natural, logical, and easier to join the fact table directly to the related dimension tables using the inner join avoiding the left(or right) joins to the Bridge table.
Even if it is needed to join 2 fact tables between each other, an experienced data engineer will do that more efficiently than doing that via Bridge table. In such a case it will be 2 big tables join instead of 3 big tables join.
In my opinion, the USS is really a brilliant solution for the Self Service BI. Once the Puppini Bridge table is built, the data analysts and business users could do their work on the BI platform concentrating on insights and not on data connectivity challenges avoiding many possible pitfalls there.
In other areas of data consuming it seems not to be that beneficial and increases the maintenance efforts.
The USS approach with its Puppini Bridge in my opinion could be used in addition to the traditional dimensional data model as a big bonus for the Self Service BI.
As long as all the fact and dimension table have a one-column based primary key, which is actually one of the best practices in dimensional modeling, it is possible to implement the Puppini Bridge Table and use it for the SelfService BI.
I did my best to review briefly the approach. USS is a really new, interesting, and not yet proved by the industry way of building Analytics. The whole idea is very interesting and really worth evaluating. In case you build a Self Service BI solution it definitely deserves to be tried out.
It is blessed by Bill Inmon, so it should survive :)
The links to the book and the podcast could be found below: