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
Intro
Dimensional Modeling and Star Schema Design
Dimensional modeling organizes analytical data around business processes. A fact table records measurements or events. Dimension tables describe the people, products, places, dates, and other contexts used to filter and group those facts.
A star schema is the common relational shape for a dimensional model. The fact table sits at the center. Each dimension connects directly to it through a key relationship.
DimDate
|
DimCustomer --- FactSales --- DimProduct
|
DimStore
The diagram is only the visible result. The design begins with a business process and a precise statement of grain: what one fact row represents. Grain controls which dimensions and measures belong in the fact table. If the grain is unclear, a query can return plausible but incorrect totals.
Why analytical data needs a different shape
Operational databases support transactions such as placing an order, changing an address, or receiving a payment. Their normalized tables reduce update anomalies and preserve transactional integrity. Analytical queries behave differently. They scan many rows, join business context, group by descriptive attributes, and summarize measures.
A star schema reshapes selected operational data for those analytical queries. Dimensions provide understandable labels and hierarchies. Facts provide events, states, and measurements at a consistent grain. The separation makes query intent visible:
- dimensions answer who, what, where, when, and how;
- facts answer what happened, how often, and how much;
- relationships determine which dimensional context applies to each fact row.
Dimensional modeling does not replace operational modeling. A warehouse or semantic model commonly receives transformed copies of operational data. The source systems remain responsible for business transactions.
Start with the business process and grain
Choose one measurable process, such as order fulfillment, inventory, subscriptions, or support cases. Avoid starting with a broad subject such as company data. A process supplies the events and measurements that the model must represent.
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
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
