Your own tables
When the data has to fit a schema that already exists (your product's tables, a warehouse, a model you are building), start from that schema instead of a description. Your table and column names, types and keys are kept exactly, and the numbers you state are held on your own columns.
Import a structure#
In Studio, choose New dataset, then Import a structure, and paste or upload any of these:
| Source | What is read |
|---|---|
| SQL DDL | CREATE TABLE statements from any common database, including pg_dump output, keys declared later with ALTER TABLE, and quoted or qualified names |
| dbt | schema.yml or manifest.json |
| Prisma, Django, SQLAlchemy, Rails | Model files and schema.rb, read as text and never run |
| DBML, Mermaid | A Table block or an erDiagram |
| OpenAPI, JSON Schema, Avro, BigQuery | Object and record definitions |
| Salesforce, HubSpot | A Salesforce object describe, or HubSpot properties or object schemas, custom objects included. See Salesforce and HubSpot |
| CSV | The header row of each file |
Several files join into one structure. Only the structure is read: no values are copied, so a schema from a production database is safe to use. Anything that cannot be kept (a type with no equivalent, a check constraint Studio does not read) is listed on the import, never dropped quietly.
What the schema declares is held in the rows: whole numbers stay whole, decimals keep their places, NOT NULL columns
are never empty, UNIQUE columns never repeat, and every foreign key points at a row that exists.
State numbers on your columns#
After the import, the plan asks what the data should show. Write it as you would for any request, naming your own tables and columns where it helps: "revenue from completed orders grows from $40k to $95k a month over 2025, 6% of orders cancelled, channels 50/35/15". Each number is bound to the columns that carry it and held there. A number the tables cannot carry (a churn rate when nothing records that an account left) is shown on the plan with why, before anything is built.
Draw the tables#
Choose Design the tables yourself on New dataset to lay tables out on a canvas. Pick each column's kind from the palette: an ID, a link to another table, a person, an email, a place, a company, a count, a number, money, a date, a choice with its shares, yes or no, text, or a formula over other columns. Each kind has its own editor: a choice's values with their shares, a number's range with its spread, a date that happens after another, how evenly rows spread across the table they link to. Sample values from your design appear on every card as you work, so you see what the data will look like before you build it.
Rules sit beside each column: unique, never empty, only filled when a condition holds, or rising with another column.
Tips#
- Import the tables a dashboard reads, not the whole warehouse. Fewer tables build faster and are easier to check.
- Give a lookup table its rows. A catalogue, a plan list or a set of regions is something the business decides, so list its rows in the design and the rest of the data picks from them.
- Name the time each row happens. An order's
created_at, a ticket'sopened_at. Studio keeps every row after the row it belongs to, and spreads activity across the window.
Prefer generating data visually?
Misata Studio lets you turn natural language prompts into relational schemas with exact outcome invariants, live preview tables, and one-click database seeding without writing code.