A Complete Beginner’s Guide to Data Warehousing
By: Parmin Sedigh
Tags: Beginners Guide, Data Warehouse, Data Analysis

A Complete Beginner’s Guide to Data Warehousing

When I was first about to meet Ahmed Elsamadisi, the founder and CEO of Narrator, I decided to actually learn about data warehousing, star and snowflake schema, and all that fun stuff. But then I realized, there weren’t any quick guides for beginners like me! So I decided to make one, with the help of Ahmed!

Photo by Kevin Ku on Unsplash

Before we go any further, I need to share something critical that I learned while talking to Ahmed about the entire data world. Definitions won’t get you anywhere. You need to understand the problems that are present in the data warehousing space and address them and knowing just knowing what a star schema is won’t help you do that.

So just wanna learn some definitions and basic ideas? Read Part 1.

For a more in-depth look at the issues currently with the data warehousing field and how to shift your mindset to become better at analysis, go to Part 2. Or do both!

Part 1: The Bare Bone Basics

Data Warehousing: storing and connecting all crucial business/company data in a single space

The main purpose of organizing data in a go-to, easy-to-access way is so that it can be analyzed later on. Or in fancier terms, it should be able to support Business Intelligence (BI) actions later on, with the most important aspect being analysis. There’s no point in having huge amounts of data if it’s super messy and can’t be analyzed for optimization! That’s where the two most popular data warehousing models come in, star schema and snowflake schema.

Star Schema: a data warehousing model that consists of fact and dimension tables, where the dimension tables are denormalized

Let’s unpack that definition. In this model, you have pieces of data called measures and others called dimensions. The measures are numerical data like the number of units sold or the number of emails opened. Dimensions give context to the measures. The dimensions for the aforementioned examples could be UnitSales and OpenedEmails, respectively.

An example of a star schema. By SqlPac at English Wikipedia, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=76901169

These measures are stored in fact tables and dimensions are stored in dimension tables. The fact tables have dimension key columns (that relate them to the dimension tables) and numeric measure columns, which store the measures.

Fact tables come in 3 distinct flavours.

Transaction fact tables: these store data about a specific, one-time event so the data is only stored once (Periodic) snapshot fact tables: as the name suggests, these store snapshot data or data at a given point in time, like the number of purchases per customer at the end of the quarter. This means the data is stored multiple times at regular intervals. Accumulating snapshot tables: and these store accumulating data, or data over time, like the total number of units of a certain product sold over time

Dimension tables can vary a lot across industries and companies but here are some of the most popular types.

Time dimension tables: these store the time at which the related measure in the corresponding fact table was true Geography dimension tables: these store, you guessed it, geographical data like city, country, postal/zip code, etc. Product dimension tables: these store information about the product like the productID, product name, and brand name Employee dimension tables: these store data about the employees like employeeID, employee name, address, etc. Range dimension tables: these store ranges of data like a time period or a range in price, which can help report later on

This is cool and all but what the denormalized thing from the definition before mean? Your data can be normalized or denormalized. Normalized data is when the data’s stored in multiple tables with relationships linking them to each other. It helps maintain more of the data’s integrity and reduces redundancy but it slows things down since the computer has to jump from one table to another, multiple times. Denormalized data which is how star schema’s organized is when everything’s organized into one main table along with some other dimension tables. The real difference is that there are only direct links to the fact table. However, normalized data can have multiple links.

Things should be clicking into place now as to why this model is called star schema. It’s because it looks like a star with a central fact table and dimension tables “fanning out” from it.

Snowflake Schema: a multidimensional data warehousing model that consists of fact and dimension tables, where the dimension tables are normalized

It’s helpful to think of a snowflake schema as having the same so-called base as a star schema. It also has a central fact table and dimension tables connected to it. However, to reduce redundancy, optimize storage, and generally clean things up, snowflake schemas have dimension tables connected to their first layer of dimension tables.

A “template” for a snowflake schema. By SqlPac — Own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=4285113

Don’t be scared off by the jargon. Here’s how Ahmed would explain a star schema to a 7-year-old!