Імпорт і експорт файлів

Імпорт зовнішніх файлів

З підменю Import контекстного меню полотна можна імпортувати п’ять форматів:

• json
• Schema SQL
• GraphQL
• DBML
• AML

Пункт Import and Add, розташований одразу під пунктом Import, додає файл до діаграми, а не замінює її — див. імпорт із додаванням.
Вітальний екран, який показує порожня діаграма, має пункт Import із тими самими п’ятьма форматами — див. вітальний екран.

Розширення перевіряються без урахування регістру. Якщо вибрати файл, розширення якого не відповідає вибраному формату, імпорт скасовується й показується повідомлення Only <format> files can be imported, де формат записано як json, sql, graphql, dbml або aml, наприклад Only sql files can be imported.

Пункт Import не об’єднує файл із поточним документом, а замінює документ, і одна відміна повертає попередню діаграму.
JSON-файл приносить із собою власні налаштування, включно з блокуваннями. Якщо файл блокує вкладку, мову генератора коду, стиль назв або тип лапок, ви й далі бачите те, що бачили, але зберігається заблоковане значення з файлу. Область перегляду, заблокована чи ні, встановлюється так, як задає файл. JSON-файл, збережений до появи блокувань, завантажується з усіма ввімкненими блокуваннями та областю перегляду з масштабом 100%.
Інші формати зберігають уже наявні у вас налаштування, включно з блокуваннями, крім області перегляду, масштаб якої спочатку становить 100%.
Парсери GraphQL, DBML і AML ніколи не дають збою: з файлу, який вони не можуть прочитати, виходить порожня діаграма, а не помилка.

JSON-файл зберігає наявні в ньому позиції. Таблиці з файлу схеми SQL, GraphQL, DBML або AML розміщуються до того, як діаграма зміниться:

• Якщо файл містить дві або більше таблиць і принаймні один зв’язок, до них застосовується автоматичне розміщення в режимі Flow: зліва направо вздовж зв’язків, починаючи від лівого верхнього кута полотна. Зв’язок таблиці із самою собою також враховується.
• Інакше вони розкладаються рядами від лівого верхнього кута, і першими йдуть таблиці з найменшою кількістю стовпців.
• Якщо розміщення триває довше за 6 секунд, з’являється повідомлення Placing tables із кнопкою Cancel. Кнопка Cancel або клавіша Escape, натиснута, поки повідомлення відображається, припиняє розміщення й натомість розкладає таблиці рядами. Ряди використовуються й без повідомлення, коли розміщення не вдається, коли результат розміщення не надходить протягом 60 секунд або коли хост не запускає спільний воркер (shared worker), — див. Web Workers.

Потім діаграма замінюється за один крок, тож проміжного стану не видно. Налаштування, яке ви змінюєте, поки таблиці розміщуються, як-от вкладка, зберігається, а якщо ви тим часом імпортуєте інший файл, застосовується імпорт, розпочатий останнім.

Редактор у режимі лише для читання нічого не завантажує через пункт Import і не пропонує пункту Import and Add.

Імпорт із додаванням

Пункт Import and Add зберігає діаграму й додає файл під нею. Він є в контекстному меню полотна та у швидкому пошуку на вкладці ERD і пропонує ті самі п’ять форматів із такою самою перевіркою розширень, як і Import.

Файл додається так само, як під час вставлення: кожна таблиця, стовпець, зв’язок, індекс, нотатка та група таблиць з нього додається як новий об’єкт, таблиці, які вже є на діаграмі, не переміщуються, і жодне налаштування не змінюється, тож налаштування JSON-файлу пропускаються.
Таблиця, назва якої вже є на діаграмі, додається як друга таблиця з тією самою назвою, а не об’єднується з наявною. Зв’язки й індекси беруться лише з файлу, тож зовнішній ключ, що посилається на таблицю, якої файл не визначає, не пов’язується з таблицею, що вже є на діаграмі.

Доданий блок опиняється одразу під усім, що містить діаграма, і вирівнюється за її лівим краєм, а в порожній діаграмі — у лівому верхньому куті. Нотатки й групи таблиць, сховані за допомогою параметрів відображення, теж враховуються, бо вони й далі займають своє місце.
Усередині блоку JSON-файл зберігає власне розміщення, включно зі своїми групами таблиць. Інші формати розміщуються так само, як під час імпорту через Import: у режимі Flow або рядами за тими самими правилами, а рамка кожної групи таблиць підганяється під її таблиці. Додані таблиці й нотатки накладаються поверх усього, що вже є.

Щойно блок з’являється, виділеним стає лише додане: нові таблиці, а також нові нотатки й групи таблиць, якщо їх показано. Якщо ви тим часом перейшли на іншу вкладку, редактор повертається на вкладку ERD, перш ніж блок з’явиться. Потім область перегляду прокручується до блоку з поточним масштабом, крім випадку, коли блок уже добре видно, — див. куди веде перехід. Одна відміна скасовує все додавання.
Файл, який парсер не може прочитати, або файл без жодної таблиці й жодної нотатки нічого не додає.

Кілька файлів схеми SQL, GraphQL, DBML або AML, доданих, поки один ще розміщується, з’являються всі в тому порядку, в якому їх почали додавати. JSON-файл, доданий тим часом, з’являється одразу після прочитання, раніше за них. Імпорт через Import або завантаження іншого документа скасовує всі файли, які ще розміщуються.

Агенти для програмування додають файл так само за допомогою режиму append інструментів імпорту MCP, який зберігає розміщення JSON-файлу, але таблиці інших форматів розкладає рядами, ніколи не в режимі Flow, — див. імпорт.

JSON

Можна імпортувати файли у форматі схеми, визначеному в редакторі. Назва файлу має закінчуватися на .json, тож файл, експортований як <database name>-<timestamp>.erd.json, імпортується назад як є; файл, що має лише розширення .erd або .vuerd, тут не приймається. Файли, збережені попередніми випусками, теж читаються.

Схема SQL

Також можна імпортувати файли схем, описані мовою SQL.
Хоча парсери зроблено якомога гнучкішими незалежно від СУБД, деякий синтаксис може не підтримуватися.
Назва файлу має закінчуватися на .sql.
Підтримуваний синтаксис можна переглянути тут.

Стовпці беруться лише з операторів CREATE TABLE. Стовпець, доданий через ALTER TABLE ... ADD COLUMN, не читається.
Елементи оператора CREATE TABLE, які не є стовпцями, пропускаються, а не читаються як стовпці: безіменне обмеження CHECK (...), LIKE і EXCLUDE у PostgreSQL, FULLTEXT і SPATIAL у MySQL, записані без INDEX або KEY, PERIOD FOR у T-SQL та SUPPLEMENTAL LOG DATA в Oracle.
Стовпець, назва якого збігається з одним із них, однаково імпортується, якщо за назвою йде вбудований тип, як у exclude BOOLEAN, або якщо назву взято в лапки, як у "check" int. Слово like без лапок, за яким іде невбудований тип, як-от like citext, читається як LIKE у PostgreSQL і пропускається.
Самі обмеження CHECK не імпортуються, бо в редакторі немає місця для їхнього зберігання.

Типи даних

Тип даних стовпця зберігається разом зі списком аргументів, навіть якщо це не вбудований тип жодної з підтримуваних баз даних.
Це стосується типу enum або складеного типу, створеного через CREATE TYPE, домену, створеного через CREATE DOMAIN, типів розширень, як-от hstore, citext і ltree, назв, уточнених назвою схеми, як-от public.mood, а також назв у лапках або квадратних дужках, як-от "MyType" і [dbo].[Phone], які зберігають свої лапки або дужки. Самі оператори CREATE TYPE, CREATE DOMAIN і CREATE EXTENSION пропускаються.
Вбудований тип втрачає свої лапки або дужки, тож [int] імпортується як int, а [nvarchar](50) — як nvarchar(50). Типи "char" і "bit" у PostgreSQL зберігають свої лапки, бо це інші типи, ніж char і bit.
Суфікси масивів зберігаються для будь-якого типу: integer[], text[3][3], integer ARRAY, mood[]. Тип UNSIGNED BIG INT у SQLite імпортується цілком.
Модифікатори UNSIGNED і ZEROFILL у MySQL та MariaDB, записані одразу після типу та його аргументів, залишаються частиною типу в тому вигляді, як їх записано: INT UNSIGNED, SMALLINT(5) UNSIGNED ZEROFILL, int unsigned із mysqldump. Модифікатор SIGNED, який діє за замовчуванням, відкидається, тож TINYINT SIGNED імпортується як TINYINT. Модифікатор, записаний після іншого параметра стовпця, як у записі INT NOT NULL UNSIGNED, який MySQL відхиляє, відкидається.
Значення ENUM(...) і SET(...) зберігають свої лапки, а лапка всередині значення подвоюється, як у ENUM('a','it''s'). Екранований зворотною скісною рискою запис 'it\'s' у MySQL так само імпортується з подвоєною лапкою. У типі STRUCT<...> з Databricks назви полів у лапках і атрибут COMMENT поля зберігають свої лапки.
Стовпець, записаний без типу, як-от безтиповий стовпець SQLite або обчислюваний стовпець AS, залишається без типу: ключове слово, як-от NOT, NULL, DEFAULT, PRIMARY чи REFERENCES, або рядок в одинарних лапках не читається як тип.

Типові значення

Конструкція DEFAULT стовпця зберігає весь свій вираз, як-от now(), 0.5, CURRENT_TIMESTAMP або ARRAY[]::text[], аж до наступного параметра стовпця, коми чи закривної дужки. Конструкція CASE ... END читається цілком.
Дужки навколо всього виразу знімаються, тож ((0)) з SQL Server імпортується як 0, а (getdate()) — як getdate(). Приведення типу літерала теж знімається, тож 'draft'::character varying із pg_dump імпортується як 'draft', а NULL::character varying — як NULL; інші приведення типів залишаються, як у ARRAY[]::text[] і lower('A'::text).
Атрибут ON UPDATE CURRENT_TIMESTAMP у MySQL відкидається, бо стовпець не має для нього місця, а типове значення перед ним залишається. Запис DEFAULT ON NULL 0 в Oracle, з FOR INSERT ONLY чи FOR INSERT AND UPDATE або без них, імпортується як 0.
Рядок із префіксом, як-от N'x', E'x', B'0', X'ff', U&'x' або _utf8mb4'x', читається як один рядок, навіть якщо всередині нього є дужка.

SQL Server Management Studio записує у скрипті типові значення після таблиць, у вигляді ALTER TABLE [dbo].[t] ADD CONSTRAINT [DF_x] DEFAULT ((1)) FOR [col]. Такий оператор задає типове значення цього стовпця, тут 1, а назва його обмеження відкидається.

Експорт схеми SQL повертає дужки там, де СУБД читає вираз типового значення лише всередині них, — див. типові значення.

Автоінкремент

Ключові слова AUTO_INCREMENT, AUTOINCREMENT і IDENTITY вмикають для стовпця параметр Auto Increment, як і GENERATED ALWAYS AS IDENTITY та GENERATED BY DEFAULT AS IDENTITY, які не залишають після себе типового значення.
Так само діє типове значення, що складається з єдиного виклику nextval() у PostgreSQL, тобто типове значення, яке отримує стовпець типу serial, записане як nextval('s') або, як це робить pg_dump, nextval('s'::regclass). Назва послідовності не зберігається. Типове значення, яке лише використовує послідовність, як-от nextval('s') + 1 або NEXT VALUE FOR s у SQL Server, залишається звичайним типовим значенням.
pg_dump записує обидва варіанти після таблиць, у вигляді ALTER TABLE [ONLY] t ALTER [COLUMN] c SET DEFAULT nextval('s'::regclass) і ALTER TABLE t ALTER [COLUMN] c ADD GENERATED ... AS IDENTITY. Кожен із цих операторів вмикає для стовпця параметр Auto Increment і очищає його типове значення. Оператори CREATE SEQUENCE, ALTER SEQUENCE і всі інші дії ALTER COLUMN пропускаються.
Стовпець, у визначенні якого вказано тип serial, bigserial або smallserial, зберігає цей тип, а параметр Auto Increment лишається вимкненим.

Редактор зберігає лише прапорець Auto Increment, а кожна СУБД під час експорту записує власну форму — див. автоінкремент. Експорт для PostgreSQL записує GENERATED ALWAYS AS IDENTITY для стовпця типу smallint, integer або bigint, хоч би в якій формі його було імпортовано, а для будь-якого іншого типу, як-от INT UNSIGNED, — лише рядок коментаря після таблиці. Параметри послідовності, як-от START WITH 100, втрачаються.
Таблиця з кількома стовпцями serial або identity імпортується з кількома стовпцями з автоінкрементом, а MySQL, MariaDB і SQL Server відхиляють таку таблицю, коли виконується її експортований SQL-код.

Первинні ключі

Первинний ключ, доданий після своєї таблиці оператором ALTER TABLE t ADD [CONSTRAINT n] PRIMARY KEY (...), позначає свої стовпці як первинний ключ.
Ключові слова CLUSTERED або NONCLUSTERED у SQL Server і USING BTREE у MySQL перед списком стовпців пропускаються під час читання, тож оператор ALTER TABLE [dbo].[Users] ADD CONSTRAINT [PK_Users] PRIMARY KEY CLUSTERED ([Id] ASC) WITH (...) ON [PRIMARY], який записує SQL Server Management Studio, робить ключем стовпець Id. Запис PRIMARY KEY NONCLUSTERED HASH (...) таблиці, оптимізованої для пам’яті, не читається ні в ALTER TABLE, ні в CREATE TABLE.

Унікальні ключі та індекси

Обмеження UNIQUE для двох або більше стовпців стає одним унікальним індексом у будь-якій формі запису: UNIQUE (a, b), UNIQUE KEY n (a, b), UNIQUE INDEX n (a, b), CONSTRAINT n UNIQUE (a, b), INDEX n UNIQUE (a, b) у визначенні таблиці SQL Server і ALTER TABLE t ADD [CONSTRAINT n] UNIQUE (a, b).
Індекс отримує назву індексу ключа, за її відсутності — назву з CONSTRAINT, інакше залишається без назви, і зберігає порядок сортування кожного стовпця. Такий індекс є альтернативним ключем.
Обмеження UNIQUE для одного стовпця в будь-якій із цих форм запису натомість позначає цей стовпець як унікальний і не додає індексу, тож обмеження UQ_<table name>_<column name>, яке записує експорт, повертається тим прапорцем, з якого його записано. Оператор CREATE UNIQUE INDEX для одного стовпця залишається унікальним індексом.

Оператор ALTER TABLE, який додає кілька ключів одночасно, як-от ADD PRIMARY KEY (id), ADD UNIQUE KEY uq_a (a, b), ADD UNIQUE KEY uq_c (c) у записі phpMyAdmin, зберігає кожен унікальний ключ із нього: uq_a імпортується як унікальний індекс із назвою uq_a, а uq_c — як прапорець унікальності стовпця c. Назва з CONSTRAINT стосується лише ключа у власній конструкції. Читаються й ADD UNIQUE INDEX IF NOT EXISTS n (...) у MariaDB та ALTER TABLE t WITH CHECK ADD ... і WITH NOCHECK ADD ... у SQL Server.
Оператори CREATE INDEX і CREATE UNIQUE INDEX читаються з уточненими назвами, як-от public.t і [dbo].[t], з CLUSTERED і NONCLUSTERED у SQL Server, з CONCURRENTLY, IF NOT EXISTS, ON ONLY і USING btree у PostgreSQL, а також зовсім без назви індексу. Файлова група ON [PRIMARY] у SQL Server ігнорується.
Параметри ключа, як-от NULLS NOT DISTINCT або USING BTREE, не сприймаються помилково як назва ключа. У списку стовпців ключа стовпець називає лише перше слово, тож b DESC NULLS LAST, b text_pattern_ops і b COLLATE "C" усі роблять ключем стовпець b, а DESC зберігається як його порядок сортування. Довжина префікса, як-от email(191), пропускається під час читання, але ключ, частиною якого є вираз, як-от lower(email), пропускається цілком.

Частковий унікальний індекс, CREATE UNIQUE INDEX ... WHERE ... або INDEX n UNIQUE (...) WHERE ... у визначенні таблиці SQL Server, імпортується як звичайний індекс із тією самою назвою та стовпцями, бо ключ, унікальний у межах усієї таблиці, був би суворішим за відфільтрований, який оголошує файл. Виняток — фільтр, що складається лише з перевірок IS NOT NULL для стовпців ключа, поєднаних через AND, тобто фільтр, потрібний SQL Server, щоб унікальний стовпець міг містити більше ніж одне значення NULL: такий ключ залишається унікальним.
Унікальний ключ, що називає стовпець, якого в таблиці немає, як-от доданий через ALTER TABLE ... ADD COLUMN, відкидається цілком, а не скорочується до наявних стовпців. Звичайний індекс зберігає наявні стовпці.

SQL Developer від Oracle і DBMS_METADATA записують власний індекс ключа як окремий оператор CREATE UNIQUE INDEX із назвою ключа або, якщо ключ не має назви й за ним іде USING INDEX, із системною назвою, як-от SYS_C0012345. Імпорт читає такий індекс, а також той, який називає ADD CONSTRAINT ... USING INDEX, як частину його ключа: складений унікальний ключ імпортується як один унікальний індекс, а первинний ключ або унікальний ключ з одного стовпця — як прапорці стовпців без додаткового індексу. Тож під час експорту назад в Oracle індекс створюється один раз.

Для MySQL, MariaDB, MSSQL, Oracle, PostgreSQL і SQLite експорт схеми SQL імпортується назад із тими самими прапорцями унікальності та індексами.
У Snowflake немає вторинних індексів, тож його експорт повертає лише унікальні ключі: складений — як унікальний індекс, а ключ з одного стовпця — як прапорець унікальності цього стовпця. Експорт для Databricks не оголошує жодної унікальності, тож нічого й не повертається.

Зовнішні ключі

Зовнішній ключ стає зв’язком у таких формах запису:

• FOREIGN KEY (...) REFERENCES t (...) на рівні таблиці, з CONSTRAINT name або без нього.
• ALTER TABLE ... ADD [CONSTRAINT name] FOREIGN KEY (...) REFERENCES t (...), зокрема ALTER TABLE t WITH CHECK ADD ... і WITH NOCHECK ADD ..., які записує SQL Server Management Studio.
• REFERENCES t (col) у визначенні стовпця, як у user_id INT REFERENCES users (id), і FOREIGN KEY REFERENCES t (col), що його у цьому місці дозволяють SQL Server і Snowflake. Посилання у визначенні стовпця на більше ніж один стовпець пропускається.

Оператор ALTER TABLE дає щонайбільше один зв’язок і лише тоді, коли його перша конструкція додає зовнішній ключ: конструкція FOREIGN KEY після конструкції ADD PRIMARY KEY або ADD UNIQUE у тому самому операторі не читається. Коли один оператор додає кілька зовнішніх ключів, як-от ADD CONSTRAINT fk1 FOREIGN KEY ..., ADD CONSTRAINT fk2 FOREIGN KEY ... у записі phpMyAdmin, читається лише останній.

Посилання REFERENCES t без списку стовпців указує на первинний ключ таблиці t, якщо цей ключ складається з одного стовпця. Якщо первинний ключ складений, зовнішній ключ пропускається.
Зовнішній ключ пропускається, і жоден із його стовпців не позначається як зовнішній ключ, якщо не знайдено жодного з його цільових стовпців або якщо кількість знайдених стовпців у двох таблицях різна, як-от коли стовпця бракує лише в одній із них. Коли в обох таблицях бракує однакової кількості його стовпців, знайдені стовпці поєднуються в пари в порядку запису, і зв’язок містить лише їх.
Кожен імпортований зв’язок має тип Zero N і є ідентифікувальним, якщо кожен із його стовпців у дочірній таблиці також є первинним ключем.

Конструкції ON DELETE і ON UPDATE кожного зовнішнього ключа стають значеннями On Delete і On Update зв’язку: NO ACTION, RESTRICT, CASCADE, SET NULL або SET DEFAULT, у будь-якому регістрі та в будь-якому порядку. Зовнішній ключ без них імпортується як Not set. Про те, як задати їх у редакторі, див. редагування зв’язків.
Список стовпців після SET NULL або SET DEFAULT у PostgreSQL, як у ON DELETE SET NULL (a_id), пропускається під час читання: дія застосовується до всього ключа, а ON UPDATE після списку однаково читається. Конструкції MATCH FULL, MATCH PARTIAL і MATCH SIMPLE пропускаються, а атрибут стовпця ON UPDATE CURRENT_TIMESTAMP у MySQL не сприймається помилково як дія.
Експорт схеми SQL імпортується назад із тими діями, які записує ця СУБД, тож дія, яку вона пропускає, як-от SET DEFAULT для MySQL, будь-яка дія ON UPDATE для Oracle або будь-що, крім NO ACTION, для Snowflake, повертається як Not set.

Коментарі

Коментарі таблиць і стовпців імпортуються з трьох синтаксисів, які читає парсер: параметра таблиці й атрибута стовпця COMMENT, які використовують MySQL, MariaDB, Snowflake і Databricks, операторів COMMENT ON TABLE і COMMENT ON COLUMN, які використовують PostgreSQL і Oracle, і розширеної властивості MS_Description, яку SQL Server задає через EXEC sp_addextendedproperty.
Коментар до таблиці чи стовпця, яких файл не визначає, ігнорується.

Виклики SQL Server читаються як з іменованими аргументами, якими SQL Server Management Studio записує кожен коментар (@name=N'MS_Description', @value=N'...', ..., @level1type=N'TABLE', @level1name=N'Users'), так і з позиційними, якими їх записує експорт редактора для MSSQL.
Коментар дає лише властивість MS_Description таблиці або одного з її стовпців на рівні 2. Інша властивість, подання, індекс чи обмеження коментаря не дають, так само як і коментар, переданий у змінній або складений за допомогою +.

У коментарі, як і в будь-якому тексті в лапках, як-от у значенні DEFAULT або в назві, взятій у лапки, подвоєна лапка означає одну лапку — так її записують mysqldump і pg_dump: 'it''s' читається як it's.
Зворотна скісна риска перед лапкою, як у записі 'it\'s' у MySQL і MariaDB, теж екранує лапку. Така лапка все ж завершує текст, якщо за нею йде пробільний символ, ,, ;, ), ], :, |, + або кінець файлу, тож 'C:\', 'C:\'::text із pg_dump і 'C:\'+name у T-SQL зберігають свою зворотну скісну риску.
Значення DEFAULT зберігає свої лапки, а лапка всередині нього записується подвоєною, хоч би як її було екрановано у файлі: 'it''s'.
Якщо на момент імпорту базою даних документа є Databricks, текст в одинарних лапках натомість підпорядковується правилам Spark: кожна зворотна скісна риска екранує символ після неї, тож 'C:\\dir' читається як C:\dir, екрановані послідовності, як-от \n, \t і \u0041, декодуються, а значення DEFAULT зберігається як 'it\'s'.

Експортована схема SQL екранує лапку всередині коментаря таблиці чи стовпця: COMMENT 'it''s' для MySQL, MariaDB і Snowflake, COMMENT ON TABLE і COMMENT ON COLUMN ... IS 'it''s' для PostgreSQL і Oracle та таке саме подвоєння, включно з назвами таблиць і стовпців, у викликах sp_addextendedproperty для MSSQL. Коментар без лапок записується як є.
Databricks натомість екранує лапку й зворотну скісну риску зворотною скісною рискою, як у COMMENT 'it\'s', тож його експорт читається назад без втрат лише тоді, коли вибраною базою даних є Databricks.
MSSQL записує кожен коментар як EXECUTE sys.sp_addextendedproperty 'MS_Description', '<comment>', 'schema', '<schema>', 'table', '<table>', а для стовпця далі йде 'column', '<column>'. Якщо параметр Bracket має значення None, таблиця з назвою sales.users дає схему sales і таблицю users, а назва без схеми належить до dbo. За будь-якого іншого значення Bracket уся назва є назвою таблиці у схемі dbo.

Коментарі не зберігаються після експорту для SQLite і повторного імпорту: SQLite записує їх як звичайні рядки --, які парсер не читає. Виклики sp_addextendedproperty з експорту для MSSQL імпортуються назад як ті самі коментарі таблиць і стовпців.

GraphQL

Можна імпортувати документ GraphQL SDL.
Визначення об’єктних типів стають таблицями, блок extend type об’єднується з типом, який він розширює, а поля інтерфейсів успадковуються типами, що їх реалізують.
Поле, типом якого є інша таблиця, стає зв’язком, а не стовпцем, і список з обох боків створює проміжну таблицю.
Поле, що не є списком, як-от buyer: User, спершу поєднується в пару з тим єдиним полем іншого типу, назва якого закінчується на By, після чого йде назва цього поля, як-от orderListByBuyer, без урахування регістру й символів підкреслення; поле з номером, як-от buyer2, поєднується так само без свого номера. Саме так генератор коду називає поля у створеному ним GraphQL-коді, коли дві таблиці мають більше ніж один спільний зв’язок або таблиця посилається сама на себе, тож такий код імпортується назад з усіма зв’язками.
Кореневі типи (Query, Mutation, Subscription), типи інтроспекції та обгортки Relay, федерації й Hasura, як-от PageInfo, *Connection, *Edge і *_aggregate, вважаються шумом і пропускаються.
Директиви @id, @primaryKey, @unique, @autoincrement, @default, @map, @relation, @column, @table, @index і @db.* враховуються.
Назва файлу має закінчуватися на .graphql, .gql або .graphqls. Файл Prisma schema.prisma не є документом GraphQL, і його не можна імпортувати тут.

DBML

Можна імпортувати файл у форматі DBML, який використовують dbdiagram.io і dbdocs.
Читаються блоки Table, TablePartial, Ref, Enum і TableGroup. Блоки Project та окремі блоки Note пропускаються без впливу на таблиці навколо них.
Приймається будь-яка форма запису посилання (ref): форма Ref: із двокрапкою, іменоване посилання, блокова форма Ref { } і параметр стовпця [ref: > table.column] у його визначенні.
Посилання «багато до багатьох» <> створює проміжну таблицю з назвою, утвореною від обох сторін.
Параметри delete і update окремого посилання стають значеннями On Delete і On Update зв’язку, як у Ref: users.id < posts.user_id [delete: cascade, update: set null]. Допустимі значення — cascade, restrict, set null, set default і no action у будь-якому регістрі. Будь-яке інше значення або відсутність параметра імпортується як Not set, а інші параметри, як-от color, ігноруються.
Параметр [ref: ...] у визначенні стовпця не передає дій, а параметри посилання <> не переносяться на проміжну таблицю. Коли той самий зовнішній ключ оголошено і у визначенні стовпця, і як окреме посилання, зберігається оголошення у визначенні стовпця, без дій.
Параметр headercolor таблиці, як у Table users [headercolor: #3498DB], стає її кольором, якщо значення — шістнадцятковий код #rgb або #rrggbb, записаний без лапок. Будь-яке інше значення відкидається, а параметр headercolor блоку TablePartial не передається таблицям, які цей блок використовують.
Кожен блок TableGroup стає групою таблиць, що містить перелічені в ньому таблиці, по одній на рядок, названі так, як їх називає Ref. Його параметр [color: ...] стає кольором групи за тим самим правилом, що й headercolor, а його примітка та інші параметри відкидаються. Таблиця, яку перелічено у двох групах, залишається в першій. Група, у якій не лишилося жодної таблиці, не створюється, незалежно від того, чи вона не перелічує жодної оголошеної у файлі таблиці, чи перелічує лише таблиці, які вже забрала попередня група. Рамка групи підганяється під її таблиці, хоч би де їх було розміщено, а коли таблиці розкладаються рядами, таблиці групи залишаються разом.
Назва файлу має закінчуватися на .dbml.

AML

Можна імпортувати файл AML (Azimutt Markup Language). Приймається як поточна форма запису, так і застаріла форма v1.
Сутності стають таблицями, а вкладені атрибути перетворюються на одну назву стовпця з крапками, як-от settings.slug.
Атрибути отримують NOT NULL, якщо їх не позначено як nullable, а конструкції, для яких у редакторі немає місця, як-от check, type і tags, відкидаються, а не відхиляються. Сутність, позначена як подання, імпортується як звичайна таблиця.
Властивість color сутності, як у users {color: red}, стає кольором її таблиці. Назви кольорів AML — red, orange, amber, yellow, lime, green, emerald, teal, cyan, sky, blue, indigo, violet, purple, fuchsia, pink, rose і gray — читаються в будь-якому регістрі, у лапках чи без них, кожна як відтінок 500 однойменного кольору Tailwind, як-от #ef4444 для red. Шістнадцятковий код у лапках, як-от "#3498db", зберігається так, як записаний; код #3498db без лапок прочитати неможливо, бо # починає коментар AML. Будь-яке інше значення, а також властивість color атрибута чи зв’язку, відкидається.
Окремий оператор rel або fk у застарілій формі запису зберігає свої властивості onDelete і onUpdate як значення On Delete і On Update зв’язку, як у rel posts(user_id) -> users(id) {onDelete: cascade, onUpdate: "set null"}. Допустимі значення — cascade, restrict, set null, set default і no action, у лапках чи без них, у будь-якому регістрі. Інші властивості відкидаються.
У зв’язку, записаному у визначенні атрибута, як-от user_id int -> users(id) {onDelete: cascade}, властивості належать атрибуту, тому вони відкидаються, а зв’язок імпортується як Not set.
Назва файлу має закінчуватися на .aml.

GraphQL, DBML і AML — формати двостороннього обміну: кожен із них також є цільовим форматом генератора коду.
DBML і AML переносять ON DELETE і ON UPDATE кожного зв’язку в обох напрямках — див. генератор коду. GraphQL не переносить жодного з них, тож після імпорту GraphQL обидва мають значення Not set.
DBML також переносить в обох напрямках кольори таблиць, без прозорості, і кожну групу таблиць, що містить хоча б одну таблицю. Група без назви повертається як group_1, group_2 і так далі, а повторювана назва групи повертається з доданим _2, _3 і так далі. AML переносить колір таблиці лише як найближчу з назв своїх кольорів, тож #FF8800 записується як orange і повертається як #f97316, а групи AML не переносить. GraphQL не переносить ні кольорів, ні груп.

Експорт

Підменю Export контекстного меню полотна має три пункти:

• json: зберігає діаграму в тому вигляді, в якому її містить файл, у форматі .erd.json: таблиці з їхніми стовпцями й індексами, зв’язки, нотатки та групи таблиць, а також налаштування, причому кожне заблоковане налаштування — з його заблокованим значенням.
• Schema SQL: відкриває вкладку схеми SQL із відкритою панеллю параметрів і кнопкою Save file у фокусі, тож натискання Enter зберігає SQL, показаний на вкладці, у файл .sql. Доти нічого не зберігається.
• Image: відкриває діалогове вікно Export image, яке зберігає діаграму у файл .png або .svg чи копіює її в буфер обміну як PNG-зображення, — див. зображення.

Усі три пункти працюють у редакторі в режимі лише для читання.

Схема SQL записує ON DELETE і ON UPDATE кожного зв’язку після його конструкції REFERENCES, спершу ON DELETE. Значення Not set нічого не записує, а дія, якої вибрана база даних не приймає, пропускається. Про те, яка СУБД які дії приймає, див. редагування зв’язків.

Кожен експортований файл має назву <database name>-<timestamp>, після якої йде його розширення, а мітка часу записується за місцевим часом у форматі yyyy-MM-dd'T'HH_mm_ss — наприклад, my-schema-2026-08-29T04_05_06.erd.json. Якщо назва бази даних порожня, замість неї використовується unnamed.
Кнопки Save file на вкладці схеми SQL і в генераторі коду називають свої файли так само. Зображення бере назву бази даних такою, якою вона була на момент відкриття діалогового вікна.

Import, Import and Add і Export також доступні у швидкому пошуку на вкладці ERD, з тими самими пунктами, що й у контекстному меню полотна.

В Obsidian не відбувається завантаження й не з’являється діалогове вікно збереження: файл записується у сховище (vault), туди, куди Obsidian кладе нові вкладення для цієї діаграми, а повідомлення показує його шлях.
Символи, які Obsidian не дозволяє в назві файлу, \ / : * ? " < > |, замінюються на -.
Файловий провідник Obsidian показує експортований файл .erd.json або .sql лише тоді, коли ввімкнено Settings → Files and links → Detect all file extensions.

Зображення

Пункт Export ▸ Image у контекстному меню полотна або у швидкому пошуку відкриває діалогове вікно Export image: попередній перегляд зображення поруч із його параметрами. Відкритий оглядач залишається відкритим під затемненою областю.

• Background: увімкнено за замовчуванням. Якщо вимкнути, полотно залишається прозорим.
• Dark mode: спочатку відповідає вигляду редактора. Поки цей параметр відповідає вигляду на екрані, зображення бере власні кольори полотна, включно зі змінами, зробленими в конструкторі теми; для іншого вигляду використовується готова тема з тим самим відтінком сірого й кольором акценту.
• Scale: 1x, 2x або 3x, за замовчуванням вибрано 2x. Цей параметр задає лише розмір PNG і копії в буфері обміну, а рядок під ним показує цей розмір у вигляді PNG <width> × <height> px.

Вибрані параметри запам’ятовуються до закриття редактора й ніколи не зберігаються в документі. Попередній перегляд малюється так само, як зображення, і перемальовується, коли змінюється параметр Background або Dark mode.

Зображення містить діаграму в тому стані, у якому вона була на момент відкриття діалогового вікна; щоб урахувати пізніші зміни, закрийте діалогове вікно й відкрийте його знову. Воно містить усю діаграму, хоч би як далеко її прокручено, обрізану до того, що малює діаграма, з відступом, і завжди малюється з масштабом 100%, незалежно від масштабу, який показує редактор, тож кожна таблиця малюється повністю. Те, що ховають параметри відображення, — зв’язки, їхні мітки ON DELETE і ON UPDATE, групи таблиць або нотатки — не малюється й не отримує місця, а групи таблиць малюються позаду всього іншого.

Зображення записують три кнопки, і кожна з них залишає діалогове вікно відкритим:

• PNG: зберігає файл .png, розмір якого дорівнює розміру діаграми в масштабі 100%, помноженому на значення Scale. PNG, завеликий для елемента canvas у браузері, записується зі зниженою роздільністю, а не спричиняє помилку: діалогове вікно заздалегідь попереджає про це повідомленням Reduced from <width> × <height> px, past what a browser canvas can hold, а після експорту з’являється повідомлення Exported at a reduced resolution.
• SVG: зберігає файл .svg розміром із діаграму в масштабі 100%, незалежно від значення Scale і без жодного зменшення. Текст у ньому залишається текстом, шрифти вказано за назвою, а не вбудовано, тож програма перегляду без шрифту редактора малює текст іншим шрифтом. Тіні пропускаються.
• Copy to clipboard: поміщає в буфер обміну PNG із вибраним значенням Scale, зменшений так само, як збережений PNG, коли елемент canvas у браузері не може його вмістити. Кнопка підтверджує дію повідомленням Copied the image to the clipboard або, якщо зображення зменшено, Copied at a reduced resolution. Якщо копіювання не вдається, бо браузер чи хост не дає доступу до буфера обміну або зображення не вдалося намалювати, повідомлення Couldn't copy the image пропонує натомість зберегти PNG.

Зображення малюється у фоновому воркері, якщо хост його запускає, тож тим часом редактором можна користуватися. Якщо це триває довше за мить, з’являється повідомлення Exporting PNG, Exporting SVG або Copying image, а в разі збою з’являється повідомлення Couldn't export the PNG або Couldn't export the SVG. Закриття діалогового вікна, поки файл ще малюється, не скасовує збереження цього файлу.

Коли діалогове вікно відкривається, фокус має кнопка PNG, а клавіша Tab переміщує фокус лише в межах вікна. Клавіша Escape, кнопка x або клацання затемненої області навколо вікна закриває його.
Поки вікно відкрите, сполучення клавіш полотна, включно з відміною та повторенням, а також копіювання й вставлення нічого не роблять. Ctrl + K (Windows/Linux) або ⌘ + K (Mac) закриває його й відкриває швидкий пошук. Ctrl + F (Windows/Linux) або ⌘ + F (Mac) закриває його й ставить текстовий курсор у поле пошуку оглядача, відкриваючи оглядач, якщо він закритий, і ніколи не закриваючи його. У редакторі, надто вузькому, щоб показати оглядач, це сполучення однаково закриває діалогове вікно, але замість переміщення текстового курсора показує сповіщення.