EntityModel.comDocs
Contents

Start here

Guides

Examples

Platforms

Compare

Reference

Learn

Derive, compare and migrate tabs

A model can hold several diagram tabs: a conceptual view, a logical model, a physical model per platform, dated versions and what-if variants. Tabs derived from one another remember their lineage, so EntityModel.com can compare them, carry changes across, and write the SQL that moves a database from one to the other.

If you're unsure what the three levels are, read Conceptual, logical and physical data models first.

Tabs

The tabs sit under the top bar. Each has its own entities, relationships, hierarchies, layout and a kind:

Kind Holds
Conceptual Entities and relationships only; attributes optional
Logical Business names, typed attributes, keys, reference lists, structs, N:N relationships
Physical Tables and columns for one platform (its dialect): foreign key columns, junction tables, audit columns
Variant A copy for a version or a what-if design

Copy a tab to start a version or a variant. Right-click a selection for Copy to tab or New tab from selection to split out a subject area.

Derive one tab from another

New tab → Derive builds a new tab from an existing one and shows a preview of every change before you accept it.

Physical → logical (reverse-engineering):

  • business names: tbl_cust_mstr → customer, cust_nm → customer_name;
  • audit, ETL and slowly-changing-dimension columns dropped;
  • relationships instead of foreign key columns, and link tables as N:N relationships;
  • lookup tables as reference data;
  • relationships missing from the database inferred from key names.

Logical → physical (forward-engineering):

  • foreign key columns added;
  • N:N relationships resolved into junction tables;
  • optional struct flattening and audit columns;
  • a target platform (PostgreSQL, MySQL, Snowflake or Databricks).

Anything → conceptual: entities and relationships only, for executive and stakeholder diagrams.

From the CLI:

node bin/em.mjs derive sales --kind logical --from physical --dry-run
node bin/em.mjs derive sales --kind physical --from logical --name "Snowflake"

Compare two tabs

Compare lists what was added, removed, renamed or changed between any two tabs. Lineage tracks renames, so tbl_cust.cust_nm and customer.customer_name are matched as the same thing rather than a delete and an add. Copy the diff as Markdown for a change log or a ticket.

node bin/em.mjs diff sales v2026_10 v2026_11 [--format json]

Generate migration SQL

From Compare, Migration SQL writes the DDL that turns the first tab's schema into the second's: CREATE TABLE, ALTER TABLE … ADD/DROP/ALTER COLUMN, DROP TABLE, with renames written as RENAME rather than drop-and-add.

node bin/em.mjs migrate sales v2026_10 v2026_11 --dialect postgres --out migrate.sql

Sync a derived tab

After the source tab changes, Sync from source re-derives just the changes made since the tab was derived. It lists new entities, new attributes, type changes and new relationships to apply. Things the source dropped are listed but not selected, so nothing you added to the target by hand is lost.

node bin/em.mjs sync sales logical physical            # list the changes
node bin/em.mjs sync sales logical physical --apply    # or --propose for review in the app

Source-to-target mappings

Derived tabs also feed Mappings: which source columns, with which transform, fill each target attribute. See Mappings, glossary and comments.