SQL Transformation Model
A named, versioned, tested SELECT statement that declares its own dependencies, turning transformation logic into reviewable software.
The unit is a single query with a name. It selects from other models by reference rather than by table name, which lets the framework infer the dependency graph and build in the right order without anyone maintaining a schedule.
What this buys is that transformation stops being a collection of procedural scripts and becomes something that can be reviewed, tested and versioned like application code. Tests attach to the model — this column is unique, this one is never null, this foreign key resolves — and run as part of the build, so a data quality regression fails a pipeline rather than surfacing in a dashboard.
The materialisation choice — view, table, or incremental — is a property of the model rather than a separate deployment concern, which makes it cheap to change when volume grows.
The failure mode at scale is a graph nobody understands: hundreds of models, deep chains, and a change at the base whose blast radius is unknowable. The countermeasures are ordinary software ones — naming conventions by layer, a limit on depth, tests at layer boundaries — and they are usually adopted after the graph is already unmanageable.