Feature deep dive

Physical model

Turn an approved logical design into a deployable schema — and work out what to change in a database that already holds your data.

Generated physical database schema
Overview

Generation instead of retyping

The physical model is derived from the logical design, not maintained beside it.

Hand-translating a logical model into tables is where most of the drift between design and database creeps in. Model One generates the physical model instead, applying your naming standards, type mappings and key strategy consistently across every table.

When the design moves on, Model One compares the version your database was built from against the current model and produces the ordered statements that close the gap. A rename stays a rename, so a table keeps its rows instead of being rebuilt empty beside the original.

Every column keeps a link back to the business concept it came from, so traceability survives all the way to production.

Walkthrough

From approved design to a running database

Four steps that take a reviewed logical model into your database platform.

Step 1

Choose the target platform

Create a physical model from the New Physical Model dialog: give it a name, pick the target database and set the schema it lives in. Model One derives the tables, columns and foreign keys from your logical design for that platform.

  • Target PostgreSQL, SQL Server, Oracle or MySQL
  • Name the model and set its schema or database
  • Tables, columns and relationships derived from the logical model
  • Keep several physical models from one logical design
New Physical Model dialog with name, target DBMS and schema fields
Step 2

Shape the tables

Where a physical name or type should differ from the logical default, record an override; they layer on top of the derived defaults, so you only set what you want to change. Not every entity belongs in every database either, so a table can be left out of this model and re-included whenever you need it.

  • Table, schema and column name overrides
  • Physical-type overrides where the derived type is not what you want
  • Exclude a table so it is left out of this model entirely
  • Keep several physical models from one logical design
Columns tab with a table name override applied and the per-column grid open
Step 3

Complete the schema

A production schema is more than tables and keys. Add indexes, check constraints and referential actions to the model, tune each index for the target database, and drop in your own SQL where the generator does not reach. Options a database does not support are shown as such rather than silently dropped.

  • Non-unique indexes, tuned per target database
  • Check constraints and ON DELETE / ON UPDATE actions
  • Your own SQL in four places in the generated script
  • Table and column comments taken from your definitions
Index tuning and check constraint fields for a demo table
Step 4

Generate, check and migrate

Generate the script for the selected platform and read the findings beside it: Model One names what the target database would reject before you run anything. When the database already exists, plan a migration from the version it is on instead, and record which version each target runs so the next migration starts from the right place.

  • Executable DDL to copy or download, one table or all
  • Findings that name what the target database would reject
  • Ordered statements from a saved version to today's design
  • Steps that could lose data flagged, and held back until you confirm
Planned migration steps grouped by risk, with the data-losing one commented out
Highlights

What makes generation dependable

Repeatable rules beat manual translation every time.

Repeatable generation

The same rules produce the same schema, so the database never quietly drifts from the design.

Built for the target

Identifiers quoted, sequences created before they are used, and anything the database would reject named up front.

Column-level traceability

Follow any column back through the logical model to the business definition behind it.

Keep exploring

What feeds the physical model

Generation is only as good as the design and the conversation behind it.

Generate a schema from your own design

Bring a model — or a database you already run — and we will generate the schema and the migration for your platform live.