Your data model is the foundation everything else is built on. Get it wrong and you'll spend the next year writing workarounds. These skills cover dimensional modeling, data warehouse design, analytics event schemas, data catalogs, and the dbt models that transform raw data into something analysts can actually use. The decisions you make here ripple through every query and report downstream.
Key takeaway
ClaudeVault's data modeling skills give Claude Code structured workflows for the six modeling disciplines that determine whether downstream queries are fast, correct, and maintainable — star and snowflake schema design in Snowflake, BigQuery, and Redshift, dbt model architecture with the staging-intermediate-marts layer pattern, analytics event schema design that prevents tracking bloat, data catalog creation for discoverability, API data connector planning, and the dimensional modeling decisions that ripple through every report and dashboard built on top of them.
When the data warehouse is a collection of tables nobody documented and analysts spend more time finding the right table than writing the query
When dbt models have grown organically with no layer separation and a single change in staging breaks five downstream marts
When the analytics event schema tracks 200 events because every clickable element got its own event and nobody can explain which ones matter
When data consumers duplicate tables because they do not trust existing ones, and there is no catalog or lineage to prove which source is authoritative
A Claude Code data modeling workflow moves from warehouse schema design through dbt transformation layers to catalog and event design, building a model that analysts can query confidently without asking an engineer what a table means.
Start with the data warehouse advisor. Claude evaluates whether a star schema, snowflake schema, or hybrid approach fits the query patterns — star schemas trade 25 to 32 percent more storage for fewer joins and faster analytical queries. The output includes fact and dimension table definitions with grain, keys, and relationship types.
The dbt model advisor organizes transformations into the three-layer architecture — staging for cleaned source mirrors, intermediate for business logic, marts for analyst-facing tables. Claude applies naming conventions (stg_, int_, fct_, dim_), sets up ref() dependencies, and structures Jinja macros for reusable logic.
Use the data modeler for entity relationship design. Claude identifies the core business entities — customers, orders, products, events — defines their attributes, relationships, and grain, and produces the ERD that bridges the conceptual model to the physical schema.
The analytics event designer builds event schemas that start from metrics, not clicks. Claude defines the events that matter for measuring product goals — acquisition, activation, retention, revenue — with structured properties, naming conventions, and a validation layer that prevents tracking bloat.
Finally, the data catalog designer creates metadata entries for every table and column — descriptions, owners, freshness, lineage, and usage patterns. Claude structures the catalog so analysts can search for data by business concept, not table name, and verify trust before building a report on it.
Outcome
A dimensional warehouse schema designed for query performance, dbt models organized in three clean layers, entity relationships documented with grain and keys, an event schema that tracks what matters, and a data catalog that makes every table findable and trustworthy.
| Skill | Best for | Complexity | Primary use case |
|---|---|---|---|
| Data Warehouse Advisor | Schema architecture decisions | Advanced | Star vs snowflake schema design with fact and dimension definitions |
| dbt Model Advisor | Transformation layer organization | Intermediate | Staging, intermediate, and marts layer architecture with naming conventions |
| Data Modeler | Entity relationship design | Intermediate | Core business entity definitions with attributes, keys, and grain |
| Analytics Event Designer | Product analytics tracking | Intermediate | Metric-driven event schemas with validation and naming standards |
| Data Catalog Designer | Data discoverability and trust | Intermediate | Metadata management, lineage tracking, and search-optimized catalogs |
| API Data Connector Designer | External data source integration | Advanced | API-to-warehouse connector design with pagination, rate limiting, and schema mapping |
Designs event tracking schemas with naming taxonomies, property schemas, and tracking plans. Use when instrumenting product analytics for user behavior tracking. Event taxonomy, tracking plan, naming convention.
Design event taxonomies, property schemas, and tracking plans that capture user behavior accurately and consistently — avoiding the common pitfall of tracking everything and analyzing nothing.
Designs database schemas with entity-relationship models, normalization analysis, and indexing strategies. Use when creating table structures for a new application or domain. Schema design, ERD, constraints, migration planning.
Design data models — entity-relationship diagrams, table structures, normalization levels, and indexes — that support the application's query patterns while maintaining data integrity and accommodatin
Designs data catalogs with metadata schemas, lineage tracking, and discoverability features. Use when building catalog structures that make data findable and trustworthy across an organization. Metadata management, data governance, search design.
Design catalog structures, metadata schemas, lineage tracking, and discoverability features that solve the data discovery problem first and governance second — because a catalog nobody uses governs no
Designs warehouse schemas using Kimball dimensional modeling with star/snowflake patterns, SCDs, and fact table strategies. Use when building a data warehouse for analytical queries. Grain declaration, dimension design, platform optimization.
Design warehouse schemas that make analytical queries fast, intuitive, and correct — choosing the right grain, dimensions, facts, and SCD strategies using Kimball dimensional modeling principles.
Reviews and designs dbt models with correct layer separation, testing, and materialization strategies. Use when building or reviewing dbt project SQL and YAML. Three-layer pattern, incremental models, test coverage.
Review dbt models for correctness, design new models with proper layer separation, and advise on project structure, testing, and materialization strategies.
Designs reliable API connectors with pagination, rate limiting, incremental sync, and error recovery. Use when building data integrations that pull from REST or GraphQL APIs. API extraction, schema mapping, connector design.
Design the data extraction layer for pulling data from REST or GraphQL APIs into databases or warehouses — handling pagination, rate limits, and failure recovery.
Star schemas use denormalized dimension tables, which means 25 to 32 percent more storage but significantly faster analytical queries because joins are reduced. Snowflake schemas normalize dimensions to save storage but require more joins. For most analytical workloads in modern warehouses, star schemas perform better. The data warehouse advisor evaluates your query patterns and recommends the right trade-off.
The standard is three layers: staging (stg_) for cleaned one-to-one mirrors of source tables, intermediate (int_) for business logic transformations, and marts (fct_ for facts, dim_ for dimensions) for analyst-facing tables. The dbt model advisor organizes existing models into this structure and sets up ref() dependencies so changes propagate cleanly.
Start from the metrics you need to move, not the actions users can take. Most product teams track too many events — 50-plus is already excessive for product and marketing analytics. The analytics event designer defines events tied to acquisition, activation, retention, and revenue goals, with structured properties and naming conventions that prevent tracking bloat.
The dbt community standard uses prefixes that indicate layer and type: stg_ for staging models, int_ for intermediate transformations, fct_ for fact tables, and dim_ for dimension tables. The dbt model advisor applies these conventions consistently and adds suffixes for specific patterns like _daily for time-grain aggregations.
Data catalogs solve the discoverability and trust problems that grow with warehouse size. Tools like Atlan, Alation, and DataHub store metadata, lineage, and usage patterns for every table. The data catalog designer skill creates the catalog entries — descriptions, owners, freshness indicators — so analysts can find data by business concept and verify its trustworthiness before building reports.