data-martUse when designing, building, or optimizing data marts — dimensional modeling (star/snowflake schemas), fact and dimension table design, conformed dimensions, slowly changing dimensions (SCD Types 1-6), aggregation strategies, ETL/ELT loading patterns, data mart bus architecture, performance optimization (indexing/partitioning/materialized views), and data …
Independent GitHub snapshot · Automated classification · Original documentation governs
Comprehensive guide to building analytical data marts using dimensional modeling (Kimball methodology). Covers schema design, fact/dimension patterns, SCD handling, ETL/ELT loading, aggregation, performance tuning, and data quality.
Detailed code examples, patterns, and configuration are in the reference files below. Read the relevant file when working on that area.
| File | Covers |
|---|---|
| fundamentals-modeling-facts.md | data mart fundamentals, dimensional modeling (star/snowflake), and fact table design |
| performance-quality.md | aggregation strategies, performance optimization, and data quality |
| scd-etl-patterns.md | slowly changing dimensions (SCD Types 1-6), conformed dimensions, and ETL/ELT loading patterns |
| Anti-Pattern | Why It Fails | Correct Approach |
|---|---|---|
| Using snowflake schema for simple marts | Adds join complexity without storage savings on modern systems; query performance degrades | Default to star schema; only snowflake when dimension tables exceed millions of rows with clear normalization benefit |
| Skipping conformed dimensions | Same customer/product means different things across marts; dashboards show contradictory numbers | Define conformed dimensions in a shared layer; all marts reference the same dimension tables |
| Loading fact tables without surrogate keys | Natural keys change (account numbers, product codes); history breaks when source systems change keys | Always use integer surrogate keys; map natural keys through dimension lookup |
| Building SCD Type 2 for every dimension | Adds complexity, storage, and ETL logic for dimensions that rarely change or where history is irrelevant | Use SCD Type 1 by default; only use Type 2 where business users explicitly need historical attribute tracking |
| No date dimension table | Repeated date parsing in queries, inconsistent fiscal calendar logic, missing holiday flags | Create a comprehensive date dimension with fiscal periods, holidays, and business day flags |
| Domain | Skill |
|---|---|
| PostgreSQL, MySQL, Redis administration | rhel-databases, ubuntu-databases |
| Python data engineering (SQLAlchemy, Alembic) | python-data-engineer |
| Enterprise database connectors (DB2, Oracle, SQL Server) | python-enterprise-connectors |
| Large file analysis (CSV, logs) | large-file-analysis |
| Performance profiling and optimization | performance |