Dimensional Modeling and Star Schema Design
Dimensional modeling organizes analytical data around measurable events and the business context used to explain them. A star schema places one fact table at the center and connects it to dimension tables for filtering, grouping, and summarizing results.
itData engineering and analytics | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Don't Panic
Don't Panic: Dimensional Modeling and Star Schema Design
A dimensional model is a way to arrange analytical data so that the questions people ask have somewhere sensible to land. At the center sits a fact table, holding events or measurements. Around it sit dimension tables, holding the dates, products, customers, stores, and other context that make those measurements less like a sack of numbers and more like an answer.
The important bit is grain, meaning exactly what one fact row represents. This is the quiet bouncer at the door. If one row is an order line, line quantity belongs there. An order total does not, unless somebody writes down how it is allocated. Otherwise a perfectly respectable sum counts the same shipping charge once per line, which is how a spreadsheet acquires confidence it has not earned.
Facts and dimensions are not a contest between numbers and labels. Facts describe what happened, how often, or how much. Dimensions make those facts filterable and groupable. A surrogate key identifies one warehouse version of a dimension row, while the natural key identifies the source business entity. That split matters when history arrives, which it will, usually wearing a badge that says urgent.
For changing attributes, Type 1 overwrites the current value. Type 2 creates a new version, so old facts keep their old context and new facts receive the new key. The surprise is that correct SQL is not the same as correct meaning. Two fact tables can join without errors and still multiply measurements. Compare processes through conformed dimensions after each fact is summarized at compatible grain.
Start with the Intro when the star shape, fact patterns, and history rules need the longer explanation. Use Slides for the design sequence at a glance. Keep the Cheatsheet open while deciding grain, aggregation, keys, and verification queries. The Practice tab turns the sequence into a repeatable design method, and the Exercise gives one order-line star a chance to reveal whether its totals can survive contact with arithmetic.
Tools can draw the schema, load the tables, and run the query. None can decide what one row means. That remains the small, unfashionable, extremely consequential sentence at the start.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://www.kimballgroup.com/wp-content/uploads/2013/08/2013.09-Kimball-Dimensional-Modeling-Techniques11.pdf
Supports
- Business process, grain, dimensions, and facts as the dimensional design sequence
- Transaction, periodic snapshot, accumulating snapshot, and factless fact patterns
- Additive, semi-additive, and non-additive facts
- Surrogate keys, conformed dimensions, role-playing dimensions, degenerate dimensions, junk dimensions, and bridge tables
- Type 0, Type 1, Type 2, and Type 3 slowly changing dimension behavior
- Drilling across fact tables through conformed dimensions
- https://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/dimensional-modeling-techniques/
Supports
- Official Kimball technique index and progression for further study
- Coverage claimed in the Kimball reference-link rationale
- https://learn.microsoft.com/en-ie/power-bi/guidance/star-schema
Supports
- Star schemas as facts connected to dimensions for filtering, grouping, and summarization
- Consistent fact-table grain and one-to-many dimension relationships
- Surrogate keys, snowflake dimensions, role-playing dimensions, junk dimensions, degenerate dimensions, and factless fact tables
- Type 1 overwrite and Type 2 versioned-row history
- Power BI relevance and the reference-link rationale
- https://learn.microsoft.com/en-us/fabric/data-warehouse/dimensional-modeling-overview
Supports
- Star schema design for analytical filtering, grouping, sorting, and summarization
- Fact and dimension table roles
- Periodic ETL loading and historical-accuracy requirements
- Iterative warehouse delivery and the reference-link rationale
- https://docs.oracle.com/en/database/oracle/oracle-database/21/dwhsg/database-data-warehousing-guide.pdf
Supports
- Star and snowflake schemas, facts, dimensions, keys, and warehouse query behavior
- Physical warehouse design and the advanced-study link rationale
- Join and aggregation validation behind the hero quiz
- https://learn.microsoft.com/en-us/sql/samples/adventureworks-install-configure
Supports
- Availability of maintained AdventureWorks sample databases for SQL Server and Azure SQL
- Practice value claimed in the reference-link rationale
- https://github.com/sindresorhus/awesome
Supports
- Discovery of the curated Awesome Data Engineering list
- https://github.com/igorbarinov/awesome-data-engineering
Supports
- Ecosystem discovery of dbt, SQLMesh, DuckDB, Apache Superset, and Metabase
- https://docs.getdbt.com/docs/introduction
Supports
- dbt models as SQL transformations with testing, documentation, dependencies, and deployment workflows
- dbt Awesome Links rationale
- https://www.getdbt.com/
Supports
- dbt product identity and code-first transformation-modeling placement
- dbt Landscape description
- https://sqlmesh.readthedocs.io/en/stable/concepts/overview/
Supports
- SQLMesh models, dependency tracking, tests, plans, and incremental deployment behavior
- SQLMesh Awesome Links rationale
- https://duckdb.org/docs/current/
Supports
- DuckDB as an analytical SQL environment for local tables and files
- DuckDB Awesome Links rationale
- https://superset.apache.org/docs/
Supports
- Apache Superset datasets, SQL connectivity, dimensions, metrics, and semantic-layer capabilities
- Apache Superset Awesome Links rationale
- https://www.metabase.com/docs/latest/
Supports
- Metabase data-model metadata, relationships, metrics, and analytical exploration
- Metabase Awesome Links rationale
- https://www.sqldbm.com/
Supports
- Collaborative visual modeling, forward and reverse engineering, and warehouse platform support
- SqlDBM Landscape placement
- https://vertabelo.com/documentation
Supports
- Browser-based logical and physical relational modeling and SQL generation
- Vertabelo Landscape placement
- https://bookshelf.erwin.com/bookshelf/public_html/2019R1/Content/User%20Guides/erwin%20Help/Dimensional_Modeling_Chapter.html
Supports
- erwin dimensional notation covering star schemas, facts, dimensions, snowflakes, and conformance
- erwin Data Modeler Landscape placement
- https://docwiki.embarcadero.com/ERStudioDA/210/en/Creating_Entity_Relational_or_Dimensional_Models
Supports
- ER Studio dimensional physical models, table roles, source lineage, facts, dimensions, and snowflakes
- ER Studio Data Architect Landscape placement
- https://help.sap.com/docs/SAP_POWERDESIGNER/856348b84a7c479489d5172a630f014d/c7c2e0646e1b1014b15599cfaffb4f4a.html
Supports
- PowerDesigner physical data models, multidimensional warehouse objects, source mappings, and generated extraction scripts
- SAP PowerDesigner Landscape placement
- https://www.oracle.com/database/sqldeveloper/technologies/sql-data-modeler/
Supports
- Free logical, relational, physical, and multidimensional modeling with forward and reverse engineering
- Oracle SQL Developer Data Modeler Landscape placement
- https://hackolade.com/help/DataModelingTechniques.html
Supports
- Dimensional modeling with fact, dimension, star, and snowflake structures across analytical targets
- Hackolade Studio Landscape placement
- https://www.kimballgroup.com/2007/07/keep-to-the-grain-in-dimensional-modeling/
Supports
- The practitioner consequences of designing facts without a declared grain
- Field Notes cards about mixed granularity and report-shaped modeling
