---

name: data-mart description: Use 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 quality frameworks. Part of the data-* skill family. disambiguation: A single subject-area mart — its star schema, conformed dimensions and consumption patterns. Enterprise-wide architecture, Kimball vs Inmon and the integration layer is data-warehouse.

Data Mart Design and Implementation

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.

---

Reference Files

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

---

Related Skills

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