How to import a database schema into Yantra Studio
Bring an existing database into Yantra Studio as a model, by whichever of the three routes matches what you can get hold of.
When this is useful
- A production database has no documentation and you have been asked to produce some.
- You are planning a migration and need the current state modelled before you can describe the target.
- You want to check a deployed schema against the standards it was supposed to follow.
Before you start
- One of: a DDL SQL script, a CSV or Excel file describing the structure, or credentials for a database you are permitted to read.
- Live database import and DDL import are separately enabled, so check which routes are available to you.
Step 1: Choose the route
Import DDL / Mermaid ER takes a script — the most common route, and the one that works regardless of network access to the database.
Import CSV / Excel takes a structure file, useful when what you were given is a spreadsheet from a DBA rather than a script.
Live DB Import connects to the database and reads it directly, which is the most accurate route when you are allowed to use it.
Data ▸ Import DDL / Mermaid ERData ▸ Import CSV / ExcelData ▸ Live DB Import
Step 2: Run the import
Supply the file or connection and let the import build the model. Entities, columns and relationships come across as modelled objects, not as pictures.
Step 3: Review what arrived
Run Validate Model and the Health Report over the result. An imported schema is the deployed reality, which is not the same as a correct model — this is usually where you find out which constraints were never actually created.
Data ▸ Validate ModelData ▸ Health Report
Step 4: Make it readable
Group the model into Subject Areas and record what the tables mean in the Data Dictionary. A 400-table import with no grouping is technically complete and practically unusable.
Data ▸ Subject AreasData ▸ Data Dictionary
What happens next
You have a model of what exists, which is the baseline for everything else: impact analysis, a Delta DDL migration to a target design, or a source-to-target mapping.
Example
A legacy order database imported from a pg_dump schema script: 180 tables in, 6 subject areas out, and a health report that identified 23 tables with no primary key.
Tips
- Import first, tidy second. Resist correcting the model during the import — the value of the first pass is that it shows the database as it really is.
- Keep the imported baseline. Comparing your target design against it later is what produces a defensible migration.
Limitations
- An import reflects what is in the script or the database. Meaning that lives only in application code cannot come across.
- Which of the three routes you have depends on what your organisation has enabled.