For those of you who are familiar with working with relational databases from application code, it is very likely they have been working with an object-relational mapper (ORM). ORMs were introduced to fill the impedance mismatch between object-oriented programming languages and the relational database schema, which works with tables. Well-known examples are Entity Framework and NHibernate.

ORMs provide a layer of abstraction that allows for the storage and retrieval of objects from a database, without worrying about the underlying table structure when doing so. To perform automated mapping of objects to tables, or the other way around, ORMs often have built-in capabilities for describing a database schema, the corresponding object model, and the mappings between them in a markup language. Most of the time, neither of these have to be written by hand. Often, they can be generated from an object model or an existing database, and the mappings between them are often, by convention, generated or drawn in a visual editor.

While all this allows for the current database schema to be defined as code, this alone does not help with coping with schema changes, yet. For handling schema changes as code, two common approaches are available. The first one describes every change in code; the other one describes only the latest version of the schema in code. These approaches are known as migration-based and state-based approaches. Both can rely on third-party tooling to use these for applying the changes to the database.