Как открыть диаграмму в mysql
От модели к физической БД в MySQL WorkBench
Внимание, поскольку WorkBench обновился, то я написал новую статью, которая состоит из теории и практики построения БД из WorkBench.
Итак, в прошлом посте, мы создали физическую базу данных и первую таблицу в базе данных, при помощи программы MySQL Workbench (в дословном переводе “Рабочая скамья” )))).
В этом посте мы узнаем, что такое модели в программе WorkBench и как с их помощью создавать взаимосвязанные таблицы (с внешними ключами), а заодно – усовершенствуем нашу базу данных для последующих экспериментов. Предыдущим методом мы могли из Workbench создавать только базу данных и какие-то отдельные таблицы.
Итак, в программе MySQL WorkBench жмем File New Model (Ctrl + N) и перед нами открывается такая картина…
Итак, все, что мы создадим сейчас будет называться моделью, программа поможет нам сформировать скрипт, который и создаст реальную базу данных.
1 Создание базы данных (схемы) в модели
Итак, начнем, с редакции имени базы данных. Терминологическое отступление. Вообще база данных ещё называется “Schema”, это синонимы, насколько я помню из книги Д. Осипова, “Базы данных и Delphi”, это произошло не сразу, а после очередного собрания “стандартизаторов” баз данных. Чтобы отредактировать название “Схемы”, нужно проделать следующее…
Перед нами открывается такое окно…
Я назвал базу данных, схему – MyDataBase1, кодировку не менял, в комментарии указал – “Первая база данных, учебная”;
После этого – жмём на крестик, на вкладке возле названия “MyDataBase1” и возвращаемся к предыдущему окну.
2 Создание таблиц в базе данных (схеме)
Итак, для того, чтобы создать таблицы – нам нужно определиться какую ситуацию будет отражать база данных. Я предлагаю сделать всё на примере студентов – все учились, всем будет понятно.
Каждый студент учится на каком-то одном факультете, поэтому, для начала предлагаю создать таблицу “Students” и таблицу “Departments”…
2 раза кликаем на AddTable и видим такую картину… Заполняем поле Table Name…
Заполняем имя таблицы. Обратите внимание на вкладки внизу, сейчас мы находимся на “Coloumns”. Для таблицы студентов разработаем несколько полей…
-Primary_key (уникальный ключ записей данной таблицы)
-Department_id (Внешний ключ, каждый студент учится на каком-то факультете, соответственно будем отмечать это в данном поле);
Итак, “PK” – поставил только у главного ключа, это поле является частью формирования уникального ключа таблицы (насколько я понял, в формировании такого ключа может участвовать несколько полей, но это в дальнейших исследованиях).
NN – Not Nulled – отсутствие нулевых полей, так как у всех студентов есть Имя, Фамилия, Возраст, Пол…
AI – автоинкрементное поле – с добавлением новой записи значение в этом поле будет увеличиваться как минимум на единицу.
Аналогично создадим и настроим таблицу Departments. В ней я создал 2 поля Primary_key и Department_name, в терминологии баз данных, получилось так..
Здесь сделаю небольшое пояснение, Deparment_id в таблице students и Primary_key, в таблице departments это практически одно и тоже, разница лишь в том, что значения внешнего ключа Deparment_id разбросаны по таблице, а Primary_key автоинкрементен в своей таблице.
3 Стартовое заполнение созданных таблиц
Для того, чтобы нам с Вами делать какие-то дальнейшие эксперименты с IDE Delphi, языком SQL и др. вещами – нужно сделать стартовое заполнение, то есть, внести хоть какие-то записи. Для этого, на каждой из таблиц переходим во вкладку Inserts. Она внизу….
Для таблицы Departments – я сделал 5 факультетов – Physics, Mathematics, History, Philosophy, Art.
Для таблицы Students 10 произвольных записей. Если будете повторять пример – можете написать, что угодно, главное, соблюдать тип данных и в автоинкрементных полях писать по порядку.
После ввода записей, не забывайте нажать “Apply Updates”
Создание связи между таблицами
Для создания связи между таблицами, сначала разберемся в типе связи. В нашей ситуации на одном факультете может учиться несколько студентов, значит связь – один ко многим. Открываем вкладку Foreign Keys, дописываем “ручками” имя ключа, я написал “MyForeignKey1”, в Referenced table выбрал Departments, а в правой части таблицы – выбрал в колонке Coloumn Department_id, поскольку это было имя внешнего ключа для таблицы Students и соответствующее поле в другой таблице Primary Key
Можно также ещё заполнить Foreign Key Options. По описанию из блога Mithandrir
В разделе “Foreign Key Options” настраиваем поведение внешнего ключа при изменении соответствующего поля (ON UPDATE) и удалении (ON DELETE) родительской записи:
Сохранение из модели в реальную / физическую базу данных
“File → Export→ Forward Engineer MySQL Create Script…”
Отмечаем необходимые галочки, мне нужна была только одна Generate INSERT Statements for Tables. Если нужно сохранить скрипт в файл – пропишите директорию в поле сверху.
В следующем окне можно настроить – какие объекты мы будем экспортировать. Если внимательно присмотреться, то у нас создано всего 2 таблицы.
Жмем далее… и получаем такой вот скрипт…
Копируем в буфер, но что дальше? Нужно этот скрипт где-то выполнить…
Выполнение скрипта – создания базы данных и таблиц
Жмем на “домик” в верхнем левом углу программы…
Потом 2 раза кликаем на MyConnection….
Перед нами открывается такая вкладка…
Это наше соединение с сервером, здесь мы и будем выполнять наш скрипт. Обратите внимание, слева базы данных, которые были созданы в программе WorkBench….
Далее, File New Query Tab… Вставляем скрипт в полученный Tab…
Теперь, нужно дать команду этот скрипт исполнить, для этого жмем в верхнем меню, Query Execute (All or Selection)
Итак, если все нормально, то в нижнем окне output, вы увидите все “зеленые галочки”. А когда нажмете Refresh в контекстном меню в списке баз данных, то увидите, вновь созданную базу mydatabase1.
Напоследок, построим ER диаграмму. ER расшифровывается как Entity Relation – удачная модель “Сущность – связь”, которая, в частности разрабатывалась Питером Ченом. Итак, возвращаемся на вкладку модели и жмем на Add Diagramm…
Далее, переносим таблицы в область диаграммы…
Мы создали связь один ко многим. На одном факультете могут учиться несколько студентов. Обратите внимание, связь возле таблицы Students расщепляется – это означает “ко многим”.
Итак, мы создали модель, из неё через выполнение скрипта – реальную базу с таблицами. А также создали диаграмму ER.
Основы работы с MySQL Workbench: быстрый старт, управление схемой данных
В первой части обзора я расскажу о самых основах работы с программой, так что, можете использовать эту статью как руководство начинающего пользователя. Вторая часть будет посвящена использованию Workbench в бою при работе с удалённым сервером. В ней я дам базовые инструкции и рекомендации по настройке подключения сервера и синхронизации с ним.
MySQL Workbench — инструмент для визуального проектирования баз данных, интегрирующий проектирование, моделирование, создание и эксплуатацию БД в единое бесшовное окружение для системы баз данных MySQL.
Должен сказать, что программа действительно великолепная. Она позволяет быстро и с удовольствием накидывать схемы данных проекта, проектировать сущности и связи между ними, безболезненно внедрять изменения в схему и так же быстро и безболезненно синхронизировать её с удалённым сервером. А графический редактор EER-диаграмм, напоминающих забавных таракашек, позволяет увидеть общую картину модели данных и насладиться её лёгкостью и элегантностью 🙂 После первой же пробы этот инструмент становится незаменимым помощником в боевом арсенале веб-программиста.
Скачать MySQL Workbench
Начало работы
Создание и редактирование модели данных
Для добавления модели нажимаем плюсик рядом с заголовком «Models» или выбираем «File → New Model» (Ctrl + N):
На этом экране вводим имя базы данных, выбираем кодировку по умолчанию и, если нужно, заполняем поле комментария. Можно приступать к созданию таблиц.
Добавление и редактирование таблицы
Список баз данных проекта и список таблиц в пределах базы данных будет располагаться во вкладке «Physical Schemas». Чтобы создать таблицу, дважды кликаем на «+Add Table»:
Откроется удобный интерфейс для редактирования списка полей и их свойств. Здесь мы можем задать название поля, тип данных, а так же установить для полей различные атрибуты: назначить поле первичным ключом (PK), пометить его Not Null (NN), бинарным (BIN), уникальным (UQ) и другие, установить для поля авто-инкремирование (AI) и значение по умолчанию (Default).
Управление индексами
Добавлять, удалять и редактировать индексы таблиц можно во вкладке «Indexes» интерфейса управления таблицей:
Вводим название индекса, выбираем его тип, затем галочками помечаем в нужном порядке список полей, участвующих в данном индексе. Порядок полей будет соответствовать порядку, в котором были проставлены галочки. В данном примере я добавил уникальный индекс к полю username.
Связи между таблицами
Установка внешних ключей и связывание таблиц возможно только для таблиц InnoDB (эта система хранения данных выбирается по умолчанию). Для управления связями в каждой таблице находится вкладка «Foreign Keys»:
В разделе «Foreign Key Options» настраиваем поведение внешнего ключа при изменении соответствующего поля (ON UPDATE) и удалении (ON DELETE) родительской записи:
В приведённом примере я добавил к дочерней таблице UserProfile внешний ключ для связи с родительской таблицей User. При редактировании поля userId и удалении позиций из таблицы User аналогичные изменения будут автоматически происходить и со связанными записями из таблицы UserProfile.
Наполнение таблицы базовыми данными
При создании проекта в базу данных часто нужно добавлять стартовые данные. Это могут быть корневые категории, пользователи-администраторы и т.д. В управлении таблицами MySQL Workbench для этого существует вкладка «Inserts»:
Как видно из примера, в случае, если перед записью в базу данных к данным нужно применить какую-то функцию MySQL, это делается с помощью синтаксиса \func functionName(‘data’), например, \func md5(‘password’).
После ввода данных необходимо сохранить их в локальную базу данных нажатием на кнопку «Apply Changes».
Создание EER диаграммы (диаграммы «сущность-связь»)
Для представления схемы данных, сущностей и их связей в графическом виде в MySQL Workbench существует редактор EER-диаграмм. Для создания диаграммы в верхней части экрана управления базой данных дважды кликаем на иконку «+Add Diagram»:
В его интерфейсе можно создавать и редактировать таблицы, добавлять между ними связи различных типов. Чтобы добавить уже существующую в схеме таблицу на диаграмму, просто перетащите её из панели «Catalog Tree».
Для экспорта схемы данных в графический файл выберите «File → Export», а затем один из вариантов (PNG, SVG, PDF, PostScript File).
Импорт существующей схемы данных (из SQL дампа)
Если у нас уже есть схема данных, её можно без труда импортировать в MySQL Workbench для дальнейшей работы. Для импорта модели из SQL файла выбираем «File → Import → Reverse Engineer MySQL Create Script. «, после чего выбираем нужный SQL файл и жмём «Execute >»
В MySQL Workbench так же предусмотрен импорт и синхронизация модели данных нарямую с удалённым сервером. Для этого потребуется создать подключение удалённого доступа к MySQL, о которых я расскажу в продолжении данного обзора.
Демо-проект из статьи доступен для скачивания по этой ссылке. Желаю успехов и красивых таракашек схем!
Как открыть диаграмму в mysql
Создание ER-диаграммы в среде MySQL Workbench
Давайте теперь поработаем с системой базы данных MyFlix Video Library, чтобы помочь понять концепцию ER-диаграмм. Мы будем использовать эту базу данных для всей практической работы в оставшейся части этого урока
MyFlix — это юридическое лицо, которое сдает в аренду фильмы своим членам. MyFlix хранит свои записи вручную. Теперь руководство хочет перейти на СУБД
Вспомним шаги по разработке диаграммы EER для базы данных:
Объекты, которые должны быть включены в нашу ER-диаграмму:
Участники — эта сущность будет хранить информацию об участниках.
Фильмы — эта сущность будет содержать информацию о фильмах
Категории — эта сущность будет содержать информацию, которая помещает фильмы в различные категории, такие как «Драма», «Действие», «Эпический» и т. Д.
Прокат фильмов — эта сущность будет хранить информацию о фильмах, сдаваемых в аренду ее членам.
Платежи — эта сущность будет хранить информацию о платежах, произведенных участниками.
Определение отношений между сущностями
Участники и фильмы
Фильмы и категории лиц
Из этого можно сделать вывод, что характер отношений между категориями и таблицей фильмов один-ко-многим.
Участники и платежные организации
Из этого можно сделать вывод, что характер взаимоотношений между участниками и платежными организациями один-ко-многим.
Теперь давайте создадим модель EER, используя MySQL Workbench
Модель улучшенного отношения сущностей (EER)
Модель Enhanced Entity Relationship (EER) — это модель данных высокого уровня, которая предоставляет расширения для исходной модели Entity Relationship (ER). EER Models поддерживает более детальный дизайн. EER Modeling появилась как решение для моделирования очень сложных баз данных.
В рабочей среде MySQL Workbench перейдите в режим моделирования и нажмите кнопку «+»
Дважды щелкните кнопку Добавить диаграмму, чтобы открыть рабочее пространство для диаграмм ER.
Появляется окно EER Diagram
Давайте посмотрим на два типа объектов, с которыми мы будем работать.
Участники организации будет иметь следующие атрибуты
Создадим таблицу участников:
Кликните по кнопке «Таблица»
В верхней части окна диаграммы появится запрос параметров для создаваемой таблицы:
Что такое Collation и зачем их так много?
Параметр Collation указывает серверу, как нужно сортировать и сравнивать строки. Вот, например, строки “Apple” и “apple”. Они разные или нет? Это зависит от указанного Collation. Если с регистром всё более менее понятно, то что делать с примером “елка” и “ёлка”? Считать их как одинаковые или как разные? Это все тоже в Collation.
В Collation есть несколько частей:
Дважды кликните мышкой по этой сущности. Появится окно свойств, показанное ниже:
Задайте название сущности (поле Table Name) и добавьте атрибуты (Column Name)
Должно получиться примерно такое:
Повторите эти действия для всех сущностей, в итоге должно получиться примерно так:
Кликаем по иконке создания связи «один-ко-многим»
Затем последовательно кликаем по внешнему ключу MemberMovie.MemberId и Member.id (нужные поля подсвечиваются под курсором)
Повторяем эти действия для всех связей, в итоге получится примерно следующее:
MySQL. Workbench. Проектируем БД. Теория и практика
Данная статья посвящена проектированию БД. Основана на книге Д. Осипова “Базы данных и Delphi” и некотором личном опыте. В качестве инструмента БД я буду использовать программу MySQL Workbench 6.3 CE.
Теория
Согласно Дмитрию Осипову при проектировании БД мы можем использовать как минимум 2 подхода.
Первый – модель ER или по другому сущность-связь.
И второй подход – нормализация.
Модель сущность-связь (ER модель Питера Чена)
Алгорим проектирования БД в псевдокоде можно изобразить, например так
–Выделить все сущности, подлежащие хранению в БД (отделы, сотрудники, заказы)
–Выявить атрибуты (у отделов – название, у сотрудников – имя, фамилия, зарплата, у заказов – имя, количество)
–Выявить взаимосвязи между сущностями – отсутствие, один к одному (1:1), один ко многим (1:M), многие ко многим (M:N). Связь один ко многим это когда в одном отделе работает несколько сотрудников, у одного поставщика несколько контрактов и так далее).
–Разделить сущности на сильные (независимые) и слабые (зависимые) – если есть взаимосвязь и одна сущность зависит от другой, то говорят, что зависимая сущность – слабая, независимая сильная. Пример – отделы и сотрудники.
–Полученную схему отобразить в диаграммах MySQL Workbench и сделать ForwardEngeneering для создания реальной физической базы данных.
Нотации ER моделей
-Нотация Питера Чена
-Нотация Crow’s foot (“Воронья лапка”)
Нотация Питера Чена
Что касается нотации Питера Чена (схематического изображения), то она может выглядеть так…
Вот принятые обозначения в нотации Питера Чена
Более сложный пример мог бы выглядеть так. Пример из английской Википедии 
Нотация Gordon Everest (Гордона Эверста). Под назаванием Crow’s Foot или Fork (вилка).
Самый простой пример мог бы выглядеть так. Как видите справа у нас “воронья лапка”, означающая связь один ко многим. Один артист может спеть несколько песен. Этот пример также из английской Википедии, который есть почти во всех русских блогах на эту тему 🙂
А вот пример из книги Дмитрия Осипова. Одна вертикальная черта означает “один”, воронья лапка справа “ко многим”.
Нормализация базы данных
В книге Д.Осипова говорится о 5 нормальных формах, для практической работы, на мой взгляд, достаточно четырех
1NF – атомарность или 1 поле 1 значение.
2NF – каждой таблице свой уникальный ключ.
3NF – 1 сущность 1 таблица (моя интерпретация)
4NF – каждую связь M:N (многие ко многим) разбить на многие к одному.
В своей книге Дмитрий приводит такой пример, берет вот такую таблицу и последовательно приводит её к 4 нормальной форме.
Как видно таблица – “плохая” в качестве БД, в одном поле несколько значений, уникального ключа нет, да и вообще все данные, все сущности в одной таблице, есть связи многие ко многим (авторы и жанры, и так далее). В общем, ни одной нормальной формы не соблюдено.
Повторим за Дмитрием вкратце его шаги
Приведение к 1NF – одно поле одно значение
Приведение ко 2NF – прописывание уникального ключа таблице. На рисунке ниже указаны ключ и поля таблицы.
Приведение к 3NF – разбиение на отдельные, независимые таблицы. Как видно из рисунка выше – все поля у нас в одной таблице, какие-то поля являются атрибутами для других, если смотреть при помощи модели Питера Чена. С точки зрения пользователя БД это очень, очень неудобно. На 3 шаге сделаем следующее – разобьем 1 большую таблицу на несколько таблиц, соответствующих сущностям и свяжем их. Атрибуты сгруппируем по сущностям. Каждой таблице пропишем свой уникальный ключ. В результате, по книге Дмитрия Осипова, у нас получится следующее.
4NF – разбить каждую зависимость многие ко многим на 2 зависимости 1 ко многим. Это можно сделать введя искусственную коммутационную таблицу.
-1 автор может написать несколько книг. И также можно сказать – несколько авторов могли написать 1 книгу. Поэтому вводим тип сущности WRITERS_BOOKS
-В 1 жанре может быть несколько книг. 1 книга может быть написана в нескольких жанрах. Вводим GENRES_BOOKS
В принципе этот ряд можно было бы и продолжить
-1 поставщик может иметь несколько контрактов. В 1 контракте может быть несколько поставщиков. Но тут наверное всё зависит от реальной задачи и ситуации. Нельзя угодить на все случаи жизни. А, конечно хочется)))
Но остановимся на том, что написано в книге Дмитрия. Для понимания, думаю, этого достаточно.
Пример из жизни – разные сотрудники выполняют разные заказы. Дмитрий в своей книге делает вот так, что вполне логично.
Практика
Итак, попробуем решить ту же задачу самостоятельно, используя все накопленные знания. Для начала – поймем, что у нас на входе и что требуется получить на выходе.
На входе
В приведенном к 1NF виде
На выходе
Готовая реляционная БД MySQL, соответствующая 4 нормальным формам.
Рисуем ER диаграмму
Идём по алгоритму, описанному выше, позволю себе его напомнить
Алгорим проектирования БД в псевдокоде можно изобразить, например так
–Выделить все сущности, подлежащие хранению в БД (отделы, сотрудники, заказы)
–Выявить атрибуты (у отделов – название, у сотрудников – имя, фамилия, зарплата, у заказов – имя, количество)
–Выявить взаимосвязи между сущностями – отсутствие, один к одному (1:1), один ко многим (1:M), многие ко многим (M:N). Связь один ко многим это когда в одном отделе работает несколько сотрудников, у одного поставщика несколько контрактов и так далее).
–Разделить сущности на сильные (независимые) и слабые (зависимые) – если есть взаимосвязь и одна сущность зависит от другой, то говорят, что зависимая сущность – слабая, независимая сильная. Пример – отделы и сотрудники.
–Полученную схему отобразить в диаграммах MySQL Workbench и сделать ForwardEngeneering для создания реальной физической базы данных.
В реальной ситуации о полях таблицы (атрибутах сущностей) мы будем догадываться, например, у человека есть руки, у клиентов есть заказы, у складов есть товары и так далее, у книжного магазина есть книги, продавцы, клиенты, поставщики, филиалы, да что угодно! Список это можно перечислять до бесконечности.
Важно при проектировании БД выделять те атрибуты, которые непосредственно относятся к решению задачи в техническом задании иначе из проектирования БД можно вообще не вылезти)))
В нашем учебном случае – все немного проще и наш список атрибутов мы можем составить из тех атрибутов, которые даны в таблице. Но это не отменяет первого этапа – поиска сущностей. Итак, поехали.
1 и 2 Этап – поиск сущностей и атрибутов
Cущности (в скобках атрибуты)
2. Contracts (ContrDate)
5. Book (Titile) // NewModel >AddDiagram
2 раза кликаем по AddDiagram. И перед нами открывается поле для действий.
Начинаем заполнять. Сначала добавим все сущности с атрибутами. А потом установим взаимосвязи.
Как добавить хотя бы 1 таблицу и заполнить её?
Заполняем таблицу так как нам надо…
Создадим таким образом все таблицы, которые нам нужны. Всего 8 таблиц как и заказывали.
Перед тем как мы будем налаживать взаимосвязи, разберемся в следующем.
В чем разница между identifying and non-identifying relationships?
Теперь, собственно попробуем наладить взаимосвязи! Но прежде, разберемся с пунктирными и непунктирными линиями во взаимосвязях.
Классные объяснения на английском находятся здесь. Больше всего мне понравилось вот это объяснение
A book belongs to an owner, and an owner can own multiple books. But the book can exist also without the owner and it can change the owner. The relationship between a book and an owner is a non-identifying relationship.
A book however is written by an author, and the author could have written multiple books. But the book needs to be written by an author it cannot exist without an author. Therefore the relationship between the book and the author is an identifying relationship.
Если книга может существовать без владельца, а она может, тогда non-identifying relationship
Если книга не может существовать без автора,а она не может, тогда identifying relationship
Технически это отражается следующим образом