Справка по форматам

Схема в DBSchema — это текст. Ниже синтаксис двух форматов и правила переноса схемы в SQL и обратно. Все примеры можно вставить в редактор целиком: он разберёт их и нарисует диаграмму.

DBML

Основной формат. Таблица описывается блоком, поля — строками «имя тип [свойства]».

Table authors {
  id bigint [pk, increment]
  full_name varchar(200) [not null]
  born_on date
  Note: 'Авторы книг'
}

Ключи, обязательность и значения по умолчанию

pk — первичный ключ, increment — счётчик.
not null — поле обязательно, unique — значение не повторяется.
default: 0 — значение по умолчанию.
note: 'текст' — пояснение к полю; Note: в блоке — к таблице.

Связи

Связь пишется прямо в поле или отдельной строкой. Стрелка показывает сторону «много».

Table authors {
  id bigint [pk, increment]
}

Table books {
  id bigint [pk, increment]
  title varchar(500) [not null]
  author_id bigint [ref: > authors.id]
}

То же самое можно записать отдельной строкой, вне таблицы:

Table authors {
  id bigint [pk]
}

Table books {
  id bigint [pk]
  author_id bigint
}

Ref: books.author_id > authors.id

> — многие к одному, < — один ко многим.
- — один к одному, <> — многие ко многим.

Индексы и перечисления

Enum loan_status {
  active
  returned
  overdue [note: 'просрочена']
}

Table loans {
  id bigint [pk]
  book_id bigint
  status loan_status [not null]

  indexes {
    (book_id, status) [name: 'loans_book_status']
  }
}

Цвет и заметки таблицы

Цвет шапки хранится в самой схеме, поэтому диаграмма выглядит одинаково у всех.

Table shelves [headercolor: #D6E4F0] {
  id int [pk]
  code varchar(10) [not null]
}

PlantUML

Второй формат. Таблица — это entity, связь — линия между сущностями.

@startuml
entity authors {
  * id : bigint <<PK>>
  --
  * full_name : varchar(200)
}

entity books {
  * id : bigint <<PK>>
  author_id : bigint <<FK>>
  --
  * title : varchar(500)
}

authors ||--o{ books
@enduml

* перед именем — обязательное поле.
<<PK>>, <<FK>>, <<UQ>> — ключи и уникальный индекс.
-- отделяет ключевые поля от остальных.
||--o{ — один ко многим; ||--|| — один к одному; }o--o{ — многие ко многим.

При экспорте редактор добавляет оформление и легенду сам. Конвертация DBML ⇄ PlantUML показывает, что потеряется: PlantUML не хранит значения по умолчанию и часть свойств полей.

Импорт и экспорт SQL

Схему можно принести дампом: «Файл → Импорт SQL». Редактор сам определяет диалект, показывает сводку и предупреждения, а затем строит схему. Подключения к работающей базе нет.

CREATE TABLE authors (
  id bigint GENERATED BY DEFAULT AS IDENTITY NOT NULL PRIMARY KEY,
  full_name varchar(200) NOT NULL
);

CREATE TABLE books (
  id bigint GENERATED BY DEFAULT AS IDENTITY NOT NULL PRIMARY KEY,
  title varchar(500) NOT NULL,
  author_id bigint
);

ALTER TABLE books ADD CONSTRAINT fk_books_author_id FOREIGN KEY (author_id) REFERENCES authors (id);

Что меняется в разных диалектах

Диалект	Счётчик	Имена	Особенности типов
PostgreSQL	`GENERATED BY DEFAULT AS IDENTITY`	без кавычек	массивы и `numeric` как есть
MySQL	`AUTO_INCREMENT`	обратные кавычки	`numeric` → `decimal`, движок InnoDB
SQL Server	`IDENTITY(1,1)`	квадратные скобки	`varchar` → `nvarchar`
SQLite	`AUTOINCREMENT`	без кавычек	типы по сродству: `TEXT`, `INTEGER`, `NUMERIC`

MariaDB читается как MySQL. Oracle пока не поддерживается.

Экспорт

SQL — для применения к базе; редактор предупредит, что не переносится в выбранный диалект.
DBML и PlantUML — файлом, чтобы положить рядом с кодом.
SVG и PNG — для вики и документации, можно выгрузить только выделенные таблицы.
PDF — для распечатки.

Открыть редактор