Как в pgadmin сделать схему бд

5

Как в pgadmin сделать схему бд

Кластер баз данных PostgreSQL содержит один или несколько именованных экземпляров баз. На уровне кластера создаются роли и некоторые другие объекты. При этом в рамках одного подключения к серверу можно обращаться к данным только одной базы — той, что была выбрана при установлении соединения.

Примечание

Пользователи кластера не обязательно будут иметь доступ ко всем базам данных этого кластера. Тот факт, что роли создаются на уровне кластера, означает только то, что в кластере не может быть двух ролей joe в разных базах данных, хотя система позволяет ограничить доступ joe только некоторыми базами данных.

База данных содержит одну или несколько именованных схем, которые в свою очередь содержат таблицы. Схемы также содержат именованные объекты других видов, включая типы данных, функции и операторы. Одно и то же имя объекта можно свободно использовать в разных схемах, например и schema1 , и myschema могут содержать таблицы с именем mytable . В отличие от баз данных, схемы не ограничивают доступ к данным: пользователи могут обращаться к объектам в любой схеме текущей базы данных, если им назначены соответствующие права.

Есть несколько возможных объяснений, для чего стоит применять схемы:

Чтобы одну базу данных могли использовать несколько пользователей, независимо друг от друга.

Чтобы объединить объекты базы данных в логические группы для облегчения управления ими.

Схемы в некотором смысле подобны каталогам в операционной системе, но они не могут быть вложенными.

5.9.1. Создание схемы

Для создания схемы используется команда CREATE SCHEMA . При этом вы определяете имя схемы по своему выбору, например так:

Чтобы создать объекты в схеме или обратиться к ним, указывайте полное имя, состоящее из имён схемы и объекта, разделённых точкой:

Этот синтаксис работает везде, где ожидается имя таблицы, включая команды модификации таблицы и команды обработки данных, обсуждаемые в следующих главах. (Для краткости мы будем говорить только о таблицах, но всё это распространяется и на другие типы именованных объектов, например, типы и функции.)

Есть ещё более общий синтаксис

но в настоящее время он поддерживается только для формального соответствия стандарту SQL. Если вы указываете базу данных, это может быть только база данных, к которой вы подключены.

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

Чтобы удалить пустую схему (не содержащую объектов), выполните:

Удалить схему со всеми содержащимися в ней объектами можно так:

Стоящий за этим общий механизм описан в Разделе 5.14.

Часто бывает нужно создать схему, владельцем которой будет другой пользователь (это один из способов ограничения пользователей пространствами имён). Сделать это можно так:

Вы даже можете опустить имя схемы, в этом случае именем схемы станет имя пользователя. Как это можно применять, описано в Подразделе 5.9.6.

Схемы с именами, начинающимися с pg_ , являются системными; пользователям не разрешено использовать такие имена.

5.9.2. Схема public

До этого мы создавали таблицы, не указывая никакие имена схем. По умолчанию такие таблицы (и другие объекты) автоматически помещаются в схему « public » . Она содержится во всех создаваемых базах данных. Таким образом, команда:

5.9.3. Путь поиска схемы

Везде писать полные имена утомительно, и часто всё равно лучше не привязывать приложения к конкретной схеме. Поэтому к таблицам обычно обращаются по неполному имени, состоящему просто из имени таблицы. Система определяет, какая именно таблица подразумевается, используя путь поиска, который представляет собой список просматриваемых схем. Подразумеваемой таблицей считается первая подходящая таблица, найденная в схемах пути. Если подходящая таблица не найдена, возникает ошибка, даже если таблица с таким именем есть в других схемах базы данных.

Возможность создавать одноимённые объекты в разных схемах усложняет написание запросов, которые должны всегда обращаться к конкретным объектам. Это также потенциально позволяет пользователям влиять на поведение запросов других пользователей, злонамеренно или случайно. Ввиду преобладания неполных имён в запросах и их использования внутри PostgreSQL , добавить схему в search_path — по сути значит доверять всем пользователям, имеющим право CREATE в этой схеме. Когда вы выполняете обычный запрос, злонамеренный пользователь может создать объекты в схеме, включённой в ваш путь поиска, и таким образом перехватывать управление и выполнять произвольные функции SQL как если бы их выполняли вы.

Первая схема в пути поиска называется текущей. Эта схема будет использоваться не только при поиске, но и при создании объектов — она будет включать таблицы, созданные командой CREATE TABLE без указания схемы.

Чтобы узнать текущий тип поиска, выполните следующую команду:

В конфигурации по умолчанию она возвращает:

Первый элемент ссылается на схему с именем текущего пользователя. Если такой схемы не существует, ссылка на неё игнорируется. Второй элемент ссылается на схему public, которую мы уже видели.

Первая существующая схема в пути поиска также считается схемой по умолчанию для новых объектов. Именно поэтому по умолчанию объекты создаются в схеме public. При указании неполной ссылки на объект в любом контексте (при модификации таблиц, изменении данных или в запросах) система просматривает путь поиска, пока не найдёт соответствующий объект. Таким образом, в конфигурации по умолчанию неполные имена могут относиться только к объектам в схеме public.

Чтобы добавить в путь нашу новую схему, мы выполняем:

(Мы опускаем компонент $user , так как здесь в нём нет необходимости.) Теперь мы можем обращаться к таблице без указания схемы:

И так как myschema — первый элемент в пути, новые объекты будут по умолчанию создаваться в этой схеме.

Мы можем также написать:

Тогда мы больше не сможем обращаться к схеме public, не написав полное имя объекта. Единственное, что отличает схему public от других, это то, что она существует по умолчанию, хотя её так же можно удалить.

В Разделе 9.26 вы узнаете, как ещё можно манипулировать путём поиска схем.

Как и для имён таблиц, путь поиска аналогично работает для имён типов данных, имён функций и имён операторов. Имена типов данных и функций можно записать в полном виде так же, как и имена таблиц. Если же вам нужно использовать в выражении полное имя оператора, для этого есть специальный способ — вы должны написать:

Такая запись необходима для избежания синтаксической неоднозначности. Пример такого выражения:

На практике пользователи часто полагаются на путь поиска, чтобы не приходилось писать такие замысловатые конструкции.

5.9.4. Схемы и права

По умолчанию пользователь не может обращаться к объектам в чужих схемах. Чтобы изменить это, владелец схемы должен дать пользователю право USAGE для данной схемы. По умолчанию все пользователи имеют это право для схемы public . Чтобы пользователи могли использовать объекты схемы, может понадобиться назначить дополнительные права на уровне объектов.

Пользователю также можно разрешить создавать объекты в схеме, не принадлежащей ему. Для этого ему нужно дать право CREATE в требуемой схеме. В базах данных, обновлённых с PostgreSQL 14 или более ранней версии, все имеют это право в схеме public . Некоторые шаблоны использования требуют запретить это:

(Первое слово « public » обозначает схему, а второе означает « каждый пользователь » . В первом случае это идентификатор, а во втором — ключевое слово, поэтому они написаны в разном регистре; вспомните указания из Подраздела 4.1.1.)

5.9.5. Схема системного каталога

В дополнение к схеме public и схемам, создаваемым пользователями, любая база данных содержит схему pg_catalog , в которой находятся системные таблицы и все встроенные типы данных, функции и операторы. pg_catalog фактически всегда является частью пути поиска. Если даже эта схема не добавлена в путь явно, она неявно просматривается до всех схем, указанных в пути. Так обеспечивается доступность встроенных имён при любых условиях. Однако вы можете явным образом поместить pg_catalog в конец пути поиска, если вам нужно, чтобы пользовательские имена переопределяли встроенные.

Так как имена системных таблиц начинаются с pg_ , такие имена лучше не использовать во избежание конфликта имён, возможного при появлении в будущем системной таблицы с тем же именем, что и ваша. (С путём поиска по умолчанию неполная ссылка будет воспринята как обращение к системной таблице.) Системные таблицы будут и дальше содержать в имени приставку pg_ , так что они не будут конфликтовать с неполными именами пользовательских таблиц, если пользователи со своей стороны не будут использовать приставку pg_ .

5.9.6. Шаблоны использования

Схемам можно найти множество применений. Для защиты от влияния недоверенных пользователей на поведение запросов других пользователей предлагается шаблон безопасного использования схем, но если этот шаблон не применяется в базе данных, пользователи, желающие безопасно выполнять в ней запросы, должны будут принимать защитные меры в начале каждого сеанса. В частности, они должны начинать каждый сеанс с присваивания пустого значения переменной search_path или каким-либо другим образом удалять из search_path схемы, доступные для записи обычным пользователям. С конфигурацией по умолчанию легко реализуются следующие шаблоны использования:

Ограничить обычных пользователей личными схемами. Для реализации этого подхода сначала убедитесь, что ни у одной схемы нет права CREATE . Затем для каждого пользователя, который будет создавать не временные объекты, создайте схему с его именем, например CREATE SCHEMA alice AUTHORIZATION alice . (Как вы знаете, путь поиска по умолчанию начинается с имени $user , вместо которого подставляется имя пользователя. Таким образом, если у всех пользователей будет отдельная схема, они по умолчанию будут обращаться к собственным схемам.) Этот шаблон позволяет безопасно использовать схемы, только если никакой недоверенный пользователь не является владельцем базы данных и не имеет права CREATEROLE . В противном случае безопасное использование схем невозможно.

В PostgreSQL 15 и выше этот подход использования поддерживается конфигурацией по умолчанию. В предыдущих версиях или при использовании базы данных, обновлённой с предыдущей версии, вам необходимо удалить право CREATE из схемы public (выполнить REVOKE CREATE ON SCHEMA public FROM PUBLIC ). Затем проверьте, нет ли в схеме public объектов с такими же именами, как у объектов в схеме pg_catalog .

Удалить схему public из пути поиска по умолчанию, изменив postgresql.conf или выполнив команду ALTER ROLE ALL SET search_path = «$user» . Затем следует предоставить права на создание объектов в схеме public. Выбираться объекты в этой схеме будут только по полному имени. Тогда как обращаться к таблицам по полному имени вполне допустимо, обращения к функциям в общей схеме всё же будут небезопасными или ненадёжными. Поэтому если вы создаёте функции или расширения в схеме public, применяйте первый шаблон. Если же нет, этот шаблон, как и первый, безопасен при условии, что никакой недоверенный пользователь не является владельцем базы данных и не имеет права CREATEROLE .

При любом подходе, устанавливая совместно используемые приложения (таблицы, которые нужны всем, дополнительные функции сторонних разработчиков и т. д.), помещайте их в отдельные схемы. Не забудьте дать другим пользователям права для доступа к этим схемам. Тогда пользователи смогут обращаться к этим дополнительным объектам по полному имени или при желании добавят эти схемы в свои пути поиска.

5.9.7. Переносимость

Стандарт SQL не поддерживает обращение в одной схеме к разным объектам, принадлежащим разным пользователям. Более того, в ряде реализаций СУБД нельзя создавать схемы с именем, отличным от имени владельца. На практике, в СУБД, реализующих только базовую поддержку схем согласно стандарту, концепции пользователя и схемы очень близки. Таким образом, многие пользователи полагают, что полное имя на самом деле образуется как имя_пользователя . имя_таблицы . И именно так будет вести себя PostgreSQL , если вы создадите схемы для каждого пользователя.

В стандарте SQL нет и понятия схемы public . Для максимального соответствия стандарту использовать схему public не следует.

Конечно, есть СУБД, в которых вообще не реализованы схемы или пространства имён поддерживают (возможно, с ограничениями) обращения к другим базам данных. Если вам потребуется работать с этими системами, максимальной переносимости вы достигнете, вообще не используя схемы.

Визуализируем разработку БД PostgreSQL

Ни для кого не секрет, что проектирование структуры БД является одной из основных и порой очень трудозатратных задач при разработке любого ПО, работающего с данными. Все мы так или иначе проектируем БД, пытаясь представить себе схему взаимосвязей таблиц, а зачастую рисуем, визуализируем структуру БД, прежде чем перенести ее в СУБД. Для моделирования баз данных MySQL есть MySQL Workbench, поставляемый разработчиком, для MS SQL есть Database Diagrams; я до недавнего времени пользовался Dia, а кто-то, может быть, использует для этих целей MS Visio. Но для PostgreSQL я не встречал ни одного адекватного решения, которое позволяло бы максимально просто и точно перенести наброски структуры БД в код ее создания в самой СУБД.

Не знаю, как могло так случиться, но нет ни одной хабрастатьи о том продукте, о котором я хочу вам рассказать.

Итак… (текст, много картинок)

Хочу представить вам opensource продукт, распространяемый по лицензии GNU General Public License 3, под названием pgModeler.

1. Прост в использовании
   Легко создавать и редактировать модели БД с помощью простого и интуитивно понятного интерфейса;
2. Поддерживает различные версии PostgreSQL
   Смоделируйте БД один раз, а затем просто экспортируйте в свою версию СУБД. В состав pgModeler входят методы генерации кода, которые дают возможность Вашим моделям быть выгруженными для различных версий PostgreSQL;
   
3. Кроссплатформенный
   Написанный с помощью Qt, pgModeler может быть скомпилирован для Windows, Linux и MacOSX. Скрипты сборки легко конфигурабельны, что помогает разрешить специфические зависимости в каждой системе;
   
4. Может быть функционально расширен с помощью плагинов
   Если Вам понадобится какой-то дополнительный функционал, то Вы легко сможете реализовать его в виде плагина к pgModeler. Шаблон плагина и документация любезно включена в сборку;
5. Является открытым ПО
   Ссылка на исходный код, расположенный на гитхабе, видна на официальном сайте невооруженным глазом.

Вы все (кроме самых любопытных, которые уже сходили по ссылке на официальную страницу), наверное, спросите, чем же уникален этот продукт?

Давайте посмотрим (картинки кликабельны).

Что ж, на вид все очень даже вкусно, но так ли это на самом деле? Предлагаю создать тестовую базу.

Для начала необходимо зарегистрировать новое подключение к СУБД в настройках (Меню->Edit->Configurations->Connections):

Добавим новую роль для нашей тестовой БД. Для этого в древовидном представлении справа необходимо вызвать контекстное меню от самой БД:

Базу автоматически создавать не будем:

да, ID для роли придется добавить вручную.

Далее добавляем новую схему:

Давайте обусловимся, что в БД у нас будут храниться информация о товарах на складах. Без движений, без остатков, просто реализуем принадлежность товара к определенному складу.

Создаем новую таблицу. Это можно сделать, например, из контекстного меню, вызванного от рабочей области (клетчатое поле):

В конструкторе создания таблицы можно сразу указать все необходимые колонки, ограничения, триггеры, правила и индексы:

После принятия всех параметров таблицы она отобразится в рабочей области:

Создаем таблицу товаров:

Не стоит создавать колонку для связи двух таблиц. Конструктор это сделает за нас.

Для связи двух таблиц предусмотрено несколько типов отношений:

Создаем отношение 1-ко-Многим:

На схеме оно будет выглядеть вот так:

Теперь мы можем выгрузить нашу схему в файл-скрипт создания, в файл-картинку или напрямую в СУБД:

а также посмотреть (без возможности изменить) скрипт создания БД для любой из поддерживаемых версий СУБД в нативном формате и в формате XML (в контекстном меню от базы данных в древовидной структуре справа):

Честно говоря, исходный код можно увидеть для каждой сущности базы данных, будь то роль, схема, база данных или просто таблица.

В качестве заключения

Что ж, заявленные автором возможности данного ПО вполне себя оправдывают. Все очень интуитивно и просто.

Данный проект сейчас находится в версии v0.4.0-rc1 и активно развивается. Функционал достаточно богат, но возможны некоторые баги и недоработки, кои, впрочем, я пока не встретил.

Думаю, pgModeler придется по вкусу всем тем, кто выбирает для своих проектов PostgreSQL в качестве основной СУБД, и он поможет вам в моделировании и визуализации ваших баз данных.

PS: я не являюсь автором pgModeler.
PPS: c автором вы можете связаться сами.

Разработка логической модели базы данных

Для работы с базами данных существует несколько возможностей:

Запуск интерактивной терминальной программы, которая позволяет вводить, редактировать и выполнять команды SQL:

Интерфейс командной строки

Использование пакета с графическим интерфейсом(GUI):

SQL Server Enterprise Manager

Написание специального приложения, используя один из нескольких доступных языков программирования, которые поддерживаются СУБД.

Далее будет рассмотрена работа в среде PostgreSQL с использованием pgAdmin.

2.2. Пример создания базы данных.

Шаг 1: Создание базы данных BookShop

Параметры новой базы данных показаны на рис.2

Рис. 2. Параметры базы данных BookShop.

При создании новой базы данных в системную таблицу pg_database (см. pg_catalog/Tables) добавляется строка, содержащая параметры этой базы данных.

Шаг 2: Создаем таблицы Книги, Поставщики, Заказчики, Заказы, Поставки.

После того, как база данных создана, можно приступать к созданию ее основных объектов  таблиц. Прежде всего, для каждого столбца любой таблицы необходимо указать определенный тип данных. В SQL nип данных задается после имени столбца с помощью соответствующего ключевого слова, потом вводятся параметры представления значений столбцов, такие как длина, значение по умолчанию и др. После определения тип данных столбца таблицы сохраняется в виде постоянной характеристики столбца и не может быть изменен.

В отношении типов данных следует помнить, что недопустимо называть объекты именами команд или использовать для этой цели другие зарезервированные слова. Типы данных  это полноценные объекты базы данных, которые хранятся в системной таблице pg_type вместе с их OID.

Создаем таблицы со следующими полями:

Шаг 3: Введение ограничений целостности.

Следующий момент в процессе создания таблиц, которому необходимо уделить особенное внимание, связан с обеспечением целостности данных. Для обеспечения целостности данных в таблицах определяются ограничения на значения столбцов (constraints). Эти ограничения могут быть введены при создании таблицы для каждого столбца в отдельности или добавлены в таблицу позже с помощью специальной команды SQL ALTER TABLE. В PostgreSQL поддерживаются следующие основные ограничения целостности:

PRIMARY KEY  первичный ключ

FOREIGN KEY/REFERENCES  внешний ключ (ссылка)

CHECK – проверка условия на значение

Ограничение первичного ключа на значение столбца используется для обеспечения уникальности данных в столбцах и в целом для обеспечения ссылочной целостности (при связывании таблиц посредством внешних ключей). Определение условия primary key для таблицы имеет несколько эффектов. Во-первых, оно устанавливает определенные условия на значение первичного ключа  запрещается введения одинаковых значений и значений NULL в те столбцы, для которых оно определено. Во-вторых, primary key создает уникальный индекс для этих столбцов, что позволяет ускорить поиск строк в таблице.

Определение условия primary key в одной таблице сам по себе не обеспечивает целостность по ссылкам. Необходимо также определить соответствующие внешние ключи тех таблиц, строки которых будут комбинироваться со строками той таблицы, где определено ограничение на значение столбца PRIMARY KEY.

Ограничение внешнего ключа на значение столбца обычно применяется вместе с предварительно определенным ограничением primary key (на самом деле достаточно ограничения UNIQUE) в ассоциируемой таблице. Условие на значение foreign key ставит в соответствие один или несколько столбцов таблицы идентичному набору столбцов другой таблицы, для которых определенно ограничение primary key (или UNIQUE). Когда обновляются или удаляются значения тех столбцов таблицы, на которые ссылаются внешние ключи других таблиц, возникает вопрос: что делать с соответствующими значениями вешних ключей? Существует несколько вариантов решения этой проблемы:

ничего не делать (no action) (это событие должно обрабатываться неким отличным от стандартного способом, иначе будет выдаваться сообщение об ошибке);

запретить любые изменения(restrict);

автоматически обновить/удалить значения соответствующих внешних ключей (cascade),

установить для внешних ключей NULL-значения (set null) (для этого соответствующие столбцы не должны иметь ограничения NOT NULL);

установить для внешних ключей значения по умолчанию (set default).

Автоматическое обновление соответствующих столбцов в разных таблицах после того, как для них определены ограничения на значение столбцов primary key и foreign key, называется декларативной ссылочной целостностью (declarative referential integrity).

Ограничение на значение столбцов primary key и foreign key обеспечивают соответствие строк связанных таблиц, потому столбцы с такими ограничениями используются для реализации операции соединения таблиц.

Наглядное представление о структуре связей между таблицами в базе данных можно получить с помощью диаграмм «таблица-связь», на которых указываются ограничения primary key и foreign key и такая характеристика связей, как степень связи. На рис. 3 показана диаграмма базы данных BookShop.

Рис. 3. Диаграмма «таблица-связь» базы данных BookShop. Сплошная линия  идентифицирующие связи, пунктирные  не идентифицирующие связи. Все связи имеют степень 1:N (N  со стороны зависимой таблицы).

Ограничение уникальности на значение столбца можно назначить для того, чтобы запретить повторение значений в любом столбце таблицы. Для столбца, входящего в состав первичного ключа, подобное ограничение не может быть определено, т.к. ограничение уникальности реализуется с помощью автоматического создания уникального индекса для столбца таблицы, а для первичного ключа также автоматически создается уникальный индекс. Однако, столбец (или столбцы, если ограничение UNIQUE определено сразу для нескольких столбцов) с ограничением UNIQUE может быть использован для связи с другими таблицами, т.е. на него могут ссылаться внешние ключи этих таблиц.

Проверочное ограничение на значение столбца устанавливает диапазон значений, которые могут быть введены в один или несколько столбцов таблицы базы данных. Ограничение check может использоваться, например, для того, чтобы установить диапазон значений, которые допускается хранить в столбце, определенном для данных числовых типов.

Процесс установки проверки значения для столбца таблицы называется связыванием (binding). Можно определить и ввести несколько проверок в один столбец. Проверка может быть определена для столбца даже в том случае, если для него уже существует какое-либо правило.

Хотя проверочные ограничения на значение работают быстрее и устанавливаются проще, но правила гибче. После определения правила оно может быть связано со столбцами нескольких таблиц, но для одного столбца можно задать лишь одно правило и несколько проверочных условий.

Как в pgadmin сделать схему бд

1. Прост в использовании
   Легко создавать и редактировать модели БД с помощью простого и интуитивно понятного интерфейса;
2. Поддерживает различные версии PostgreSQL
   Смоделируйте БД один раз, а затем просто экспортируйте в свою версию СУБД. В состав pgModeler входят методы генерации кода, которые дают возможность Вашим моделям быть выгруженными для различных версий PostgreSQL;
   
3. Кроссплатформенный
   Написанный с помощью Qt, pgModeler может быть скомпилирован для Windows, Linux и MacOSX. Скрипты сборки легко конфигурабельны, что помогает разрешить специфические зависимости в каждой системе;
   
4. Может быть функционально расширен с помощью плагинов
   Если Вам понадобится какой-то дополнительный функционал, то Вы легко сможете реализовать его в виде плагина к pgModeler. Шаблон плагина и документация любезно включена в сборку;
5. Является открытым ПО
   Ссылка на исходный код, расположенный на гитхабе, видна на официальном сайте невооруженным глазом.

Для начала необходимо зарегистрировать новое подключение к СУБД в настройках (Меню->Edit->Configurations->Connections):

Добавим новую роль для нашей тестовой БД. Для этого в древовидном представлении справа необходимо вызвать контекстное меню от самой БД:

Базу автоматически создавать не будем:

да, ID для роли придется добавить вручную.

Далее добавляем новую схему:

Создаем новую таблицу. Это можно сделать, например, из контекстного меню, вызванного от рабочей области (клетчатое поле):

В конструкторе создания таблицы можно сразу указать все необходимые колонки, ограничения, триггеры, правила и индексы:

После принятия всех параметров таблицы она отобразится в рабочей области:

Создаем таблицу товаров:

Не стоит создавать колонку для связи двух таблиц. Конструктор это сделает за нас.

Для связи двух таблиц предусмотрено несколько типов отношений:

Создаем отношение 1-ко-Многим:

На схеме оно будет выглядеть вот так:

Теперь мы можем выгрузить нашу схему в файл-скрипт создания, в файл-картинку или напрямую в СУБД:

а также посмотреть (без возможности изменить) скрипт создания БД для любой из поддерживаемых версий СУБД в нативном формате и в формате XML (в контекстном меню от базы данных в древовидной структуре справа):

Как в pgadmin сделать схему бд

5.8.2. Схема public

ERD Tool¶

The Entity-Relationship Diagram (ERD) tool is a database design tool that provides a graphical representation of database tables, columns, and inter-relationships. ERD can give sufficient information for the database administrator to follow when developing and maintaining the database. The ERD Tool allows you to:

Design and visualize the database tables and their relationships.

Add notes to the diagram.

Auto-align the tables and links for cleaner visualization.

Save the diagram and open it later to continue working on it.

Generate ready to run SQL from the database design.

Generate the database diagram for an existing database.

Drag and drop tables from browser tree to the diagram.

You can open multiple copies of the ERD tool in individual tabs simultaneously. To close a copy of the ERD tool, click the X in the upper-right hand corner of the tab bar.

Toolbar¶

The ERD Tool toolbar uses context-sensitive icons that provide shortcuts to frequently performed tasks. The option is enabled for the highlighted icon and is disabled for the grayed-out icon.

Hover over an icon on Toolbar to display a tooltip that describes the icon’s functionality.

File Options¶

Click the Open File icon to load a previously saved diagram.

Click the Save icon to perform a quick-save of a previously saved diagram, or to save the diagram to a file.

Click the Save As to open a new browser dialog and specify a new location to save the diagram.

Export Options¶

Click the Generate SQL icon to generate the DDL SQL for the diagram and open a query tool with the generated SQL ready for execution.

Option + Ctrl + S

Click the Download image icon to save the ERD diagram in a image formate

Option + Ctrl + I

Editing Options¶

Click this button to add a new table to the diagram. On clicking, this will open a table dialog where you can put the table details.

Option/Alt + Ctrl + A

Click this button to edit a table on the diagram. On clicking, this will open a table dialog where you can change table details. This will enable when a table is selected.

Option/Alt + Ctrl + E

Click this button to clone the complete table structure, name it with a auto generated name and put it in the diagram.

Option/Alt + Ctrl + C

You can drop a table or link using this button. You need to select a table or link and click on this button to drop it.

Option/Alt + Ctrl + D

Table Relationship Options¶

Click this button to open a one-to-many relationship dialog to add a relationship between the two tables. The selected table becomes the referencing table and will have the many endpoint of the link.

Option/Alt + Ctrl + O

Click this button to open a many-to-many relationship dialog to add a relationship between the two tables. This option will create a new table based on the selected columns for the two relating tables and link them.

Option/Alt + Ctrl + M

Utility Options¶

Click this button to make notes on tables nodes while designing the database.

Option/Alt + Ctrl + N

Click this button to auto align all tables and links to make it look more cleaner.

Option/Alt + Ctrl + L

Click this button to toggle the column details visibility. It allows you to show few or more column details.

Option/Alt + Shift + D

Zoom Options¶

Click this button to zoom in/out automatically and fit all the tables to the view.

Option/Alt + Shift + F

Click this button to zoom in the diagram.

Click this button to zoom out the diagram.

Table Dialog¶

The table dialog allows you to:

Change the table structure details.

It can be used edit an existing table or add a new one.

Refer table dialog for information on different fields.

Table Node¶

The table node shows table details in a graphical representation:

The top bar has a details toggle button that is used to toggle column details visibility. There is also a note button that is visible only if there is some note added. you can click on this button to quickly change the note.

The first row shows the schema name of the table. Eg. public in above image.

The second row shows the table name. Eg. users in above image.

All other rows below the table name are the columns of the table along with data type. If the column is a primary key then it will have lock key icon eg. id is the primary key in above image. Otherwise, it will have column icon.

you can click on the node and drag to move on the canvas.

Upon double click on the table node or by clicking the edit button from the toolbar, the table dialog opens where you can change the table details. Refer table dialog for information on different fields.

The One to Many Link Dialog¶

The one to many link dialog allows you to:

Add a foreign key relationship between two tables.

Local Table is the table that references a table and has the many end point.

Local Column the column that references.

Referenced Table is the table that is being referred and has the one end point.

Referenced Column the column that is being referred.

The Many to Many Link Dialog¶

The many to many link dialog allows you to:

Add a many to many relationship between two tables.

It creates a relationship tables having columns derived from the two tables and link them to the tables.

Left Table is the first table that is to be linked. It will receive the one endpoint of the link with the new relation table.

Left Column the column of the first table, that will always be a primary key.

Right Table is the second table that is to be linked. It will receive the one endpoint of the link with the new relation table.

Right Column the column of the second table, that will always be a primary key.

The Table Link¶

The table link shows relationship between tables:

The single line endpoint of the link shows the column that is being referred.

The three line endpoint of the link shows the column that refers.

If one of the columns that is being referred or that refers is removed from the table then the link will get dropped.

you can click on the link and drag to move on the canvas.

The Table Notes¶

You can use the notes popup to mark some notes while designing the database.

You open the pop-up using the toolbar note button.

If some note is added to a table then it will have notes button on the table node. You can click on the button to check/update notes.