Short answer
Data modeling defines durable concepts, relationships, and grain so people can interpret information consistently as systems and reporting needs change.
About Data modeling
Data modeling structures data concepts and relationships so information remains accurate and useful. It makes grain, keys, definitions, and dependencies explicit enough for others to use safely.
Use this competency for
- Roles that design schemas, semantic models, or shared analytical entities.
- Work where multiple reports or systems depend on stable definitions and relationships.
Do not use this competency for
- Use analytics engineering when the main responsibility is implementing, testing, and operating transformations rather than defining the model itself.
Important distinctions
Analytics engineering
Analytics engineering builds dependable transformations, while data modeling defines the concepts, grain, and relationships those transformations implement.
Data governance
Data governance assigns rules and accountability, while data modeling specifies how information is structured.
Expectations by level
IC1
IC1: Defined models
Implements small, well-defined model changes with guidance. Preserves declared grain and relationships and verifies that outputs match the agreed concept.
Observable behaviors
- States the grain of each model before adding fields or joins.
- Uses documented keys and checks that joins do not duplicate records.
- Updates field definitions when a model changes.
Examples
- Adds a status field to an order model and verifies one row still represents one order.
- Builds a simple customer dimension from approved sources and documents how duplicate identifiers are handled.
IC2
IC2: Domain models
Independently designs models for a team domain with multiple sources and changing requirements. Resolves ambiguous definitions and protects downstream uses.
Observable behaviors
- Maps business concepts to entities, relationships, keys, and history rules.
- Tests alternative model designs against known reporting and operational use cases.
- Plans compatible migrations when grain or definitions change.
Examples
- Redesigns subscription history so upgrades and cancellations can be measured without overwriting prior states.
- Aligns product and billing identifiers in a shared account model and documents unmatched cases.
IC3
IC3: Shared modeling standards
Sets modeling direction for connected domains used by multiple teams. Resolves cross-domain conflicts and reviews designs for durable meaning and safe evolution.
Observable behaviors
- Defines shared conventions for grain, naming, history, and conformed entities.
- Mediates conflicting domain definitions and records the chosen boundary.
- Reviews high-impact model changes for migration risk and downstream interpretation.
Examples
- Creates a shared customer model that separates account, contract, and user concepts used across finance and product.
- Leads a migration from event-level revenue logic to recognized-revenue entities with parallel validation.