Data Modeling Recruiting

Data modeling is the craft of arranging data so that queries are fast, definitions survive change, and history stays honest. It spans normalized relational schema design for transactional systems, dimensional modeling for analytics, and Data Vault architecture for enterprises that need audit-grade history. The craft sits under pressure from both directions: cloud warehouses changed the economics of joins, and wide pre-joined tables now compete with the classic star schema. dbt's dimensional modeling guide captures the shift: cheap storage, BI tools that handle joins well, and stronger analyst skills have made wide tables a competitive option against traditional fact and dimension separation [1][1] A complete guide to dimensional modeling with dbt — dbt Labs (accessed 2026-09-28). Kimball's framework still anchors the discipline: declaring the grain is the pivotal step in a dimensional design, the binding contract every fact and dimension must honor [2][2] Grain (Dimensional Modeling Techniques) — Kimball Group (accessed 2026-09-28). Hiring for this craft means finding people who have enforced that contract, not just drawn diagrams.

Challenges in Data Modeling Recruiting

Dimensional modeling still owns the business-facing layer

The Kimball school organizes analytics data into facts and dimensions: facts are the measures of a business process, dimensions the descriptive context, and a star schema joins one fact table to each dimension [1][1] A complete guide to dimensional modeling with dbt — dbt Labs (accessed 2026-09-28). The discipline has absorbed decades of technique that a diagram cannot show. The four-step design process runs from selecting the business process through declaring the grain to identifying dimensions and facts, and the grain decision is where most designs are won or lost [2][2] Grain (Dimensional Modeling Techniques) — Kimball Group (accessed 2026-09-28). Kimball insists on atomic grain, the lowest level at which a process is captured, because it withstands unpredictable user questions, while summary grains presuppose the business's common questions [2][2] Grain (Dimensional Modeling Techniques) — Kimball Group (accessed 2026-09-28). A modeler who has carried real designs can state the grain of every fact table they ever built and defend it. That is the one question that separates practitioners from people who have read the vocabulary.

Star schema modeling without slowly changing dimensions is a demo, not a warehouse

Dimensions change: a customer moves, a product is re-categorized, a territory is reassigned. Kimball's taxonomy of responses is the core craft. Type 1 overwrites the attribute and quietly rewrites history; Type 2 adds a new dimension row so facts keep pointing at the value that was true when they occurred; Type 3 adds a column to preserve the prior value alongside the current one [3][3] Slowly Changing Dimensions — Kimball Group (accessed 2026-09-28). Each has consequences that only production ownership teaches. A Type 1 correction must be applied to every copy of the dimension or drill-across queries corrupt; a Type 2 dimension needs surrogate keys, current-row flags, and careful versioning of aggregates [3][3] Slowly Changing Dimensions — Kimball Group (accessed 2026-09-28). Interview candidates who describe slowly changing dimensions from documentation know the labels. Candidates who have run them can explain which attributes their last design tracked as Type 2, what the versioning cost was, and which stakeholder fought the history change and lost.

Snowflake schema normalization trades joins for maintenance

A snowflake schema normalizes dimension tables, linking them to other dimension tables instead of denormalizing each into a single wide table [1][1] A complete guide to dimensional modeling with dbt — dbt Labs (accessed 2026-09-28). The design choice is old, and the underlying tension is the one IBM's normalization guidance describes: normalization eliminates redundant data and the update anomalies that come with it, but it can multiply tables and degrade query performance when joins stack up [4][4] What Is Database Normalization? — IBM (accessed 2026-09-28). Insertion, deletion, and update anomalies are the concrete costs of the alternative [4][4] What Is Database Normalization? — IBM (accessed 2026-09-28). On cloud warehouses, the arithmetic has shifted: joins are cheaper than they were on traditional engines, but they are not free, and the snowflake pattern survives where dimension attributes genuinely change on their own schedule. Practitioners who have run both structures can say why a particular hierarchy earned its own tables and where they stopped normalizing. That judgment is the hire; the pattern vocabulary is public.

Data Vault architecture survives source systems the star cannot

Data Vault architecture organizes the warehouse as hubs for business keys, links for relationships, and satellites for descriptive attributes over time, all insert-only [5][5] The Data Vault Handbook: Concepts and Applications — Scalefree (accessed 2026-09-28). The handbook is explicit about the mechanics: business keys are hashed into fixed-length keys, and a hashdiff hashes the satellite's descriptive attributes so change detection becomes a single comparison [5][5] The Data Vault Handbook: Concepts and Applications — Scalefree (accessed 2026-09-28). Scalefree's writing on hash keys explains the architectural payoff: hashing removes the lookup dependency that forced hubs to load before links and satellites, so every entity loads in parallel and joins span heterogeneous platforms [6][6] Hash Keys in Data Vault — Scalefree (accessed 2026-09-28). Raw vault holds uninterpreted source data under hard rules only; business vault applies soft rules through computed satellites, point-in-time tables, and bridge tables [5][5] The Data Vault Handbook: Concepts and Applications — Scalefree (accessed 2026-09-28). A specialist who has operated data vault architecture can walk a load dependency graph and name which rules were deferred to the business vault. A tourist reproduces the hub-link-satellite diagram from training.

Relational schema design for OLTP normalizes against update anomalies

Normalization is the other school entirely. IBM's reference lays out the forms: first normal form demands atomic values and a primary key; second removes partial dependencies on composite keys; third removes transitive dependencies, where a non-key attribute depends on another non-key attribute [4][4] What Is Database Normalization? — IBM (accessed 2026-09-28). The point is operational integrity for transactional systems: a department name stored in every employee row is an update anomaly waiting to fire, corrected in one row and stale in thousands of others [4][4] What Is Database Normalization? — IBM (accessed 2026-09-28). This craft is where data modeling borders application development: relational schema design for an order system, a billing ledger, or a patient registry optimizes for write correctness, not query convenience. The population overlaps only partially with warehouse modelers, and interviewers who test both schools with the same questions read neither.

One big table benchmarks beat star schemas until definitions change

Fivetran benchmarked the question against Redshift, Snowflake, and BigQuery and found denormalized single-table designs substantially faster, with improvements around 25 to 50 percent depending on warehouse [7][7] Star Schema vs. OBT for Data Warehouse Performance — Fivetran (accessed 2026-09-28). The one big table pattern earns its place on cloud platforms: no joins, direct scans, simple pipelines. What the benchmark does not measure is what happens to business logic when it is embedded in a wide table. dbt's guide notes that a fact and dimension separation keeps definitions in one place, while wide tables duplicate them [1][1] A complete guide to dimensional modeling with dbt — dbt Labs (accessed 2026-09-28). The honest hire knows both sides: which tables in their estate stayed wide, which stayed dimensional, and what broke when a duplicated definition drifted. Candidates who treat one big table as either heresy or a universal answer have not owned the decision.

The grain they declared settles dimensional modeling claims

Modeling CVs carry the same nouns: star schema, Data Vault, normalization, marts. Verification therefore asks for the decisions behind the nouns. What was the grain of the largest fact table they owned, and what request came in that would have violated it? Which dimensions ran Type 2, and what did history queries cost? For Data Vault work, which hash function, which load dependencies, and which soft rules stayed out of the raw vault? The cost of a miss lands in months: a fact table whose grain no one can restate, dimensions silently overwriting history, joins nobody can untangle, and rework paid in analyst hours while dashboards disagree about the same customer. A practitioner who can narrate those decisions in their own project history is the hire; everyone else has read the same books.