وارد کردن یا صادر کردن فایل‌ها

وارد کردن فایل‌های خارجی

از زیرمنوی 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 Worker را ببینید.

سپس نمودار در یک گام جایگزین می‌شود، بنابراین در این فاصله چیزی نمایش داده نمی‌شود. تنظیمی که در حین چیده شدن جدول‌ها تغییر می‌دهید، مانند زبانه، حفظ می‌شود، و اگر در این میان فایل دیگری وارد کنید، وارد کردنی که آخر از همه شروع شده است اعمال می‌شود.

ویرایشگر فقط خواندنی از 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 وارد نمی‌شوند، چون ویرایشگر جایی برای نگه داشتن آن‌ها ندارد.

انواع داده

نوع دادهٔ ستون، همراه با فهرست آرگومان‌هایش، حفظ می‌شود، حتی وقتی نوع داخلی هیچ‌یک از پایگاه‌های دادهٔ پشتیبانی‌شده نباشد.
این شامل نوع شمارشی یا نوع مرکبی است که با 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، روی ستون smallint، integer یا bigint، صرف‌نظر از شکلی که وارد شده بود، GENERATED ALWAYS AS IDENTITY را می‌نویسد، و روی هر نوع دیگری، مانند INT UNSIGNED، فقط یک خط توضیح پس از جدول می‌نویسد. گزینه‌های دنباله مانند START WITH 100 از دست می‌روند.
جدولی با چند ستون serial یا identity با چند ستون دارای افزایش خودکار وارد می‌شود، و MySQL، MariaDB و SQL Server هنگام اجرای خروجی صادرشدهٔ آن، چنین جدولی را نمی‌پذیرند.

کلیدهای اصلی

کلید اصلی‌ای که پس از جدولش اضافه شود، یعنی 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 که چند کلید را یک‌جا اضافه می‌کند، آن‌طور که phpMyAdmin ADD PRIMARY KEY (id), ADD UNIQUE KEY uq_a (a, b), ADD UNIQUE KEY uq_c (c) را می‌نویسد، همهٔ کلیدهای یکتای درون خود را نگه می‌دارد: 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، شاخص را فقط یک بار ایجاد می‌کند.

خروجی طرح‌واره SQL برای MySQL، MariaDB، MSSQL، Oracle، PostgreSQL و SQLite، با همان پرچم‌های یکتا و شاخص‌ها دوباره وارد می‌شود.
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 در همان دستور خوانده نمی‌شود. وقتی یک دستور چند کلید خارجی اضافه کند، آن‌طور که phpMyAdmin ADD CONSTRAINT fk1 FOREIGN KEY ..., ADD CONSTRAINT fk2 FOREIGN KEY ... را می‌نویسد، فقط آخرین آن‌ها خوانده می‌شود.

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 خوانده می‌شود.
بک‌اسلش پیش از گیومه، آن‌طور که MySQL و MariaDB 'it\'s' را می‌نویسند، نیز گیومه را گریز می‌دهد. چنین گیومه‌ای همچنان متن را پایان می‌دهد وقتی پس از آن فاصلهٔ خالی، ,، ;، )، ]، :، |، + یا پایان فایل بیاید، بنابراین '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، federation و Hasura مانند PageInfo، *Connection، *Edge و *_aggregate به‌عنوان نویز در نظر گرفته و نادیده گرفته می‌شوند.
دستورالعمل‌های @id، @primaryKey، @unique، @autoincrement، @default، @map، @relation، @column، @table، @index و @db.* رعایت می‌شوند.
نام فایل باید به .graphql، .gql یا .graphqls ختم شود. فایل schema.prisma در Prisma یک سند GraphQL نیست و نمی‌توان آن را اینجا وارد کرد.

DBML

می‌توانید فایل DBML، قالبی که dbdiagram.io و dbdocs به کار می‌برند، وارد کنید.
بلوک‌های Table، TablePartial، Ref، Enum و TableGroup خوانده می‌شوند. بلوک‌های Project و بلوک‌های مستقل Note بدون اثر گذاشتن بر جدول‌های اطرافشان نادیده گرفته می‌شوند.
همهٔ نگارش‌های ref پذیرفته می‌شوند: شکل دونقطه‌ای Ref:، ref نام‌دار، شکل بلوکی Ref { } و تنظیم ستونی درون‌خطی [ref: > table.column].
ref چندبه‌چند <> یک جدول واسط ایجاد می‌کند که به نام هر دو سمت نام‌گذاری می‌شود.
تنظیم‌های delete و update یک ref مستقل به 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: ...] هیچ کنشی را منتقل نمی‌کند، و تنظیم‌های ref <> به جدول واسط منتقل نمی‌شوند. وقتی یک کلید خارجی هم به‌صورت درون‌خطی و هم به‌صورت ref مستقل اعلام شود، نمونهٔ درون‌خطی، بدون کنش‌ها، نگه داشته می‌شود.
تنظیم headercolor یک جدول، مانند Table users [headercolor: #3498DB]، وقتی مقدار یک کد هگز #rgb یا #rrggbb بدون گیومه باشد، به رنگ آن جدول تبدیل می‌شود. هر مقدار دیگری حذف می‌شود، و headercolor یک TablePartial به جدول‌هایی که از آن استفاده می‌کنند منتقل نمی‌شود.
هر TableGroup به یک گروه جدول تبدیل می‌شود که جدول‌هایی را در بر دارد که فهرست می‌کند، هر کدام در یک خط و با همان نامی که Ref آن‌ها را نام می‌برد. [color: ...] آن، طبق همان قاعدهٔ headercolor، به رنگ گروه تبدیل می‌شود، و یادداشت (note) و تنظیم‌های دیگرش حذف می‌شوند. جدولی که در دو گروه فهرست شده باشد، در گروه نخست می‌ماند. گروهی که بی‌جدول بماند ایجاد نمی‌شود، چه هیچ‌یک از جدول‌هایی که فهرست می‌کند در فایل اعلام نشده باشد، چه فقط جدول‌هایی را فهرست کند که گروهی پیش‌تر برداشته است. کادر گروه، هر جا که جدول‌هایش چیده شوند، به اندازهٔ آن‌ها تنظیم می‌شود، و وقتی جدول‌ها در ردیف‌ها چیده شوند، جدول‌های یک گروه کنار هم می‌مانند.
نام فایل باید به .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 برمی‌گردد، و هیچ گروهی را منتقل نمی‌کند. 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 هیچ کادر گفت‌وگوی دانلود یا ذخیره ظاهر نمی‌شود: فایل در خزانه نوشته می‌شود، همان جایی که 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 برای بوم مرورگر بیش از حد بزرگ باشد، به‌جای شکست خوردن، با وضوح کمتر نوشته می‌شود: کادر گفت‌وگو از پیش با 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 ذخیره‌شده وضوحش کاهش می‌یابد. کپی را با 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) کادر را می‌بندد و مکان‌نما را در فیلد یافتن کاوشگر قرار می‌دهد، و اگر کاوشگر بسته باشد آن را باز می‌کند و هرگز آن را نمی‌بندد. در ویرایشگری که برای نمایش کاوشگر بیش از حد باریک است، این کلید همچنان کادر را می‌بندد اما به‌جای جابه‌جا کردن مکان‌نما یک اعلان نشان می‌دهد.