Concept · from data model to database structure

Coming soon

ChiralSchema

The structure between ChiralData and the database.

ChiralData describes state and operations. ChiralSchema turns that model into a database structure: entities, fields, relations, and the changes that keep it evolving. Still a concept; there is no CLI kit to install yet.

A model needs a shape it can persist.

ChiralSchema is the layer between the data model and a database. It defines the persisted shape, inspects what exists, and describes safe, versioned change.

Define the structure

Entities, fields, keys, and constraints describe how ChiralData's model is laid out for storage.

Evolve with intent

As a concept, migrations compare the declared model with the database, then record deliberate changes while preserving existing data.

Keep the model and database in agreement.

A data model can be clear in code and still drift from what is stored. ChiralSchema names that boundary: it describes the database shape, observes what is already there, and makes change visible over time.

From model to persisted structure.

The six layers move from a data contract to entities and relations, then pair planned migrations with inspection of the database. Versions and database targets complete the path to persistence.

The six layers of ChiralSchema

A concept map from model to database: contracts, entities, relations, migration and inspection, versioned evolution, and database targets. These layers describe the intended boundary; they are not a claim that a CLI kit has shipped.

See the cross-domain framing in Chiral Architecture
Open the full chirality scene

Contracts

Ring 0

The database-facing shape of the model: field types, keys, and constraints that state what can be persisted.

Entities

Ring 1a

Named records and their fields, expressed as the tables or collections a database can store.

Relations

Ring 1b

Links between entities, including ownership, cardinality, and the keys that keep references intact.

Migration ↔ Inspection

Ring 2

The paired directions: describe a schema change, then inspect the database to understand the structure that exists.

Versions

Ring 3

A history of schema changes that can be reviewed and applied in order, so each step has a known starting point.

Database targets

Ring 5

The boundary where the schema meets a database dialect or adapter and becomes a physical, persisted structure.

ChiralFM