Part 09: Star Schema

In computing, the star schema is the simplest style of data mart schema and is the approach most widely used to develop dimensional data marts. The star schema consists of one or more fact tables referencing any number of dimension tables. The star schema is an important special case of the snowflake schema, and is more effective for handling simpler queries.

The star schema gets its name from the physical model’s resemblance to a star shape with a fact table at its center and the dimension tables surrounding it representing the star’s points.

Theory first

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. 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.

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 sales people
  • 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.

Example follows – a small star for sales data

The example below shows a transaction fact table of sales with three keys for products, dates and stores and two measures orders[#] and revenue [currency]. There are three dimension tables product, date and store which contain different elements like the store name (Store_Name) and the location (Store_City).

Star Schema For Sales

Star Schema For Sales

With this data model it is possible to see how many orders were placed in which time in which store and which products were sold. You cannot see anything about your employees for example.


  • Simpler queries – star schema join logic is generally simpler than the join logic required to retrieve data from a highly normalized transactional schemas.
  • 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.


The main disadvantage of the star schema is that data integrity is not enforced as well as it is in a highly normalized database. One-off inserts and updates can result in data anomalies which normalized schemas are designed to avoid.


About Tobias Riedner
Tobias Riedner foundet in 2015. He works and worked as innovator, consultant, analyst and educator in the fields of business intelligence and data warehousing. He learned a lot from the best consultants, managers und educators in the past and shares his knowledge worldwide. He works for a steady growing traditional company which is a leader in industry 4.0.