דילוג לתוכן הראשי

ייבוא וייצוא של קבצים

ייבוא קבצים חיצוניים​

ניתן לייבא חמישה פורמטים, מתפריט המשנה 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.

הוספת קובץ SQL דרך Import and Add &gt; Schema SQL, נחיתת הטבלאות שלו מתחת לתרשים, פרוסות לאורך הקשרים ביניהן ונבחרות

הקובץ נכנס כמו בהדבקה: כל טבלה, עמודה, קשר, אינדקס, פתק וקבוצת טבלאות שהוא מכיל נוספים כפריטים חדשים, הטבלאות שכבר נמצאות בתרשים אינן זזות, ואף הגדרה אינה משתנה, כך שההגדרות של קובץ JSON אינן נכללות.
טבלה ששמה כבר קיים בתרשים נוספת כטבלה שנייה באותו שם, ואינה מתמזגת עם הקיימת. קשרים ואינדקסים מגיעים רק מהקובץ, כך שמפתח זר לטבלה שהקובץ אינו מגדיר אינו מקושר לטבלה שכבר נמצאת בתרשים.

הבלוק שנוסף נוחת ממש מתחת לכל מה שהתרשים מכיל, מיושר לקצה השמאלי שלו, או בפינה השמאלית העליונה של תרשים ריק. גם פתקים וקבוצות טבלאות שהוסתרו באמצעות אפשרויות התצוגה נלקחים בחשבון, כי הם עדיין נמצאים שם.
בתוך הבלוק, קובץ JSON שומר על הסידור שלו, כולל קבוצות הטבלאות שלו. הפורמטים האחרים ממוקמים כפי ש-Import ממקם אותם, באמצעות Flow או בשורות לפי אותם כללים, והמלבן של כל קבוצת טבלאות מותאם סביב הטבלאות שלה. הטבלאות והפתקים שנוספו מונחים בסדר השכבות מעל כל מה שכבר נמצא שם.

כשהבלוק נוחת, רק מה שנוסף נבחר: הטבלאות החדשות, וגם הפתקים וקבוצות הטבלאות החדשים כל עוד הם מוצגים. אם בינתיים עברו לכרטיסייה אחרת, העורך חוזר לכרטיסיית ERD לפני שהבלוק נוחת. לאחר מכן התצוגה נגללת אל הבלוק ברמת הזום הנוכחית, אלא אם הוא כבר נראה היטב – ראו היכן נוחתת קפיצה. ביטול פעולה אחד מבטל את ההוספה כולה.
קובץ שהמנתח אינו יכול לקרוא, או קובץ שאין בו אף טבלה ואף פתק, אינו מוסיף דבר.

כמה קובצי סכמת SQL, GraphQL, DBML או AML שנוספים בזמן שאחד מהם עדיין ממוקם נוחתים כולם, לפי הסדר שבו התחילו. קובץ JSON שנוסף בינתיים נוחת ברגע שהוא נקרא, לפניהם. ייבוא באמצעות Import, או טעינה של מסמך אחר, מבטלים את כל הקבצים שעדיין ממוקמים.

סוכני קוד מוסיפים קובץ באותו אופן באמצעות המצב append של כלי הייבוא של MCP, ששומר על הסידור של קובץ JSON אבל מסדר את הטבלאות של הפורמטים האחרים בשורות, ולעולם לא באמצעות Flow – ראו ייבוא.

JSON​

ניתן לייבא קבצים בפורמט הסכמה שמוגדר בעורך. שם הקובץ חייב להסתיים ב-.json, כך שקובץ מיוצא בשם <database name>-<timestamp>.erd.json מיובא בחזרה כמות שהוא; קובץ שמסתיים ב-.erd או ב-.vuerd בלבד אינו מתקבל כאן. גם קבצים שנשמרו בגרסאות קודמות נקראים.

ייבוא קובץ שמור דרך Import &gt; json, שמחליף את מסמך הטיוטה יחד עם ההגדרות שלו

סכמת SQL​

ניתן גם לייבא קובצי סכמה שמוגדרים ב-SQL.
אף שהמנתחים נבנו גמישים ככל האפשר ללא תלות במסד הנתונים, ייתכן שתחביר מסוים לא נתמך.
שם הקובץ חייב להסתיים ב-.sql.
ניתן לבדוק כאן את התחביר הנתמך.

ייבוא קובץ SQL דרך Import &gt; Schema 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 דוחים טבלה כזו כשמריצים את הייצוא שלה.

מפתחות ראשיים​

מפתח ראשי שנוסף אחרי הטבלה שלו, 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 ו-DBMS_METADATA של Oracle כותבים את האינדקס של המפתח עצמו כ-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. לגבי הגדרתן בעורך, ראו עריכת קשרים.
רשימת העמודות של PostgreSQL אחרי SET NULL או SET DEFAULT, כמו ב-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), סוגי introspection, והעטיפות של 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, וההערה שלו והגדרות אחרות מושמטות. טבלה ששתי קבוצות מונות נשארת בראשונה. קבוצה שלא נותרה בה אף טבלה אינה נוצרת, בין שאינה מונה אף טבלה שהקובץ מצהיר עליה ובין שהיא מונה רק טבלאות שקבוצה קודמת כבר לקחה. המלבן של הקבוצה מותאם סביב הטבלאות שלה בכל מקום שבו הן ממוקמות, וכשהטבלאות מסודרות בשורות, הטבלאות של קבוצה נשארות יחד.
שם הקובץ חייב להסתיים ב-.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: תצוגה מקדימה של התמונה לצד האפשרויות שלה. הסייר, כשהוא פתוח, נשאר פתוח מתחת לאזור המעומעם.

פתיחת Export &gt; Image, כיבוי מצב כהה והרקע, בחירה ב-3x והעתקת התמונה ללוח

  • 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 במקום זאת.

התמונה מצוירת ב-worker ברקע כשהסביבה המארחת מריצה worker כזה, כך שהעורך נשאר זמין לשימוש בינתיים. הודעה 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) סוגר אותה ומציב את סמן הטקסט בשדה האיתור של הסייר, ופותח את הסייר אם הוא סגור, ולעולם אינו סוגר אותו. בעורך צר מדי להצגת הסייר, הצירוף עדיין סוגר את תיבת הדו-שיח, אבל מציג הודעה קופצת במקום להזיז את סמן הטקסט.