shkolaput.ru 1

1.Иерархическая модель данных. Сетевая модель данных.

Иерархическая модель данных



Представление связей в иерархической модели.

Иерархическая модель является ограниченным подтипом сетевой модели.

Имеет древовидную структуру.

Основное правило: никакой потомок не может существовать без своего родителя.

В иерархической модели узел может иметь только одного родителя.

У каждого предка (родителя) от 0 до множества потомков (детей).

Данные - коллекции записей, связи — наборы, запись - узел.

Иерархическая модель может быть представлена как древовидный граф с записями в виде узлов (которые также называются сегментами) и множествами в виде ребер.

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

Плюсы:


  1. Эффективное использование памяти ЭВМ.

  2. Быстрое выполнение основных операций над данными.

  3. Поддержка целостностей связей.

  4. Удобство для иерархически представленной информации.


Минусы:

  1. Громоздкость при работе с данными со сложными логическими связями.

  2. Огранисенность удобного пользования.

  3. Нет средств явного указания ограничений на данные.


Автоматически поддерживается целостность ссылок между предками и потомками.

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

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


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


Также можно встретить следующее описание типов иерархической модели.

Тип «дерево» является составным.

-Он включает в себя подтипы («поддеревья»), каждый из которых, в свою очередь, является типом «дерево».

-Каждый из типов «де­рево» состоит из одного «корневого» типа и упорядоченного набора (возможно пустого) подчиненных типов.

-Каждый из элементарных типов, включенных в тип «дере­во», является простым или составным типом «запись».

-Простая «запись» состоит из одного типа, например, числового, а составная «запись» объединяет некоторую сово­купность типов, например, целое, строку символов и указатель (ссылку).

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


Сетевая модель данных – модель, состоящая из записей, элементов данных и связей типа “один ко многим” (1:М), установленных между записями.


Данные представлены в виде коллекций записей, связи - в виде наборов.

В отличие от реляционной модели, связи здесь явным образом моделируются наборами, которые реализуются с помощью указателей (ссылок).

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


Сетевая БД состоит из набора записей и набора соответствующих связей. На форматирование связи особых ограничений не накладывается.

Физическое размещение данных в базах сетевого типа может быть организовано практически теми же методами, что и в иерархических базах.

Представление связей в сетевой модели

Плюсы:


  1. Больше возможностей организации связей. (произвольных связей)

  2. Соотношение используемой памяти / скорости.

Минусы:

  1. Слабый контроль целостности (из-за произвольных связей)

  2. Жесткость схемы БД

  3. Сложность для понимания и обработки данных обычным пользователям.



К числу важнейших операций манипулирования данными баз сетевого типа можно отнести следующие:

  • поиск записи в БД;

  • переход от предка к первому потомку;

  • переход от потомка к предку;

  • создание новой записи;

  • удаление текущей записи;

  • обновление текущей записи;

  • включение записи в связь;

  • исключение записи из связи;

  • изменение связей и т.д.


2.Постреляционная модель данных.

Расширенная версия реляционной модели.

Сняла ограничение неделимости данных, хранящихся в записях таблиц.

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

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

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


Аналогичным образом связаны все вторые значения столбцов и т.д.

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

Поскольку постреляционная модель допускает хранение в таблицах ненормализованных данных, возникает проблема обеспечения целостности и непротиворечивости данных. Эта проблема решается включением в СУБД механизмов, подобных хранимым процедурам в клиент-серверных системах.

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

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

Коды конверсии, наоборот, выполняются после обработки данных.


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

Недостатком постреляционной модели является сложность решения проблемы обеспечения целостности и непротиворечивости хранимых данных.

Плюсы:


  1. Много таблиц в одной.

  2. Наглядно и быстро.

Минусы:

  1. Сложность обеспечения целостности.

  2. Сложность обеспечения противоречивости.



3.Объектно-ориентированная модель данных.

Объектно-ориентированная база данных — база данных, в которой данные оформлены в виде моделей объектов, включающих прикладные программы, которые управляются внешними событиями.

Результатом совмещения возможностей (особенностей) баз данных и возможностей объектно-ориентированных языков программирования являются Объектно-ориентированные системы управления базами данных (ООСУБД).


ООСУБД позволяет работать с объектами баз данных также, как с объектами в программировании на ООЯП. ООСУБД расширяет языки программирования, прозрачно вводя долговременные данные, управление параллелизмом, восстановление данных, ассоциированные запросы и другие возможности.

Некоторые объектно-ориентированные базы данных разработаны для плотного взаимодействия с такими объектно-ориентированными языками программирования как Python, Java, C#, Visual Basic .NET, C++, Objective-C и Smalltalk; другие имеют свои собственные языки программирования.

ООСУБД использую точно такую же модель, что и объектно-ориентированные языки программирования.

Объектно-ориентированные базы данных обычно рекомендованы для тех случаев, когда требуется высокопроизводительная обработка данных, имеющих сложную структуру.

В манифесте ООБД (Atkinson et al., 1989) предлагаются обязательные характеристики, которым должна отвечать любая ООБД. Их выбор основан на 2 критериях: система должна быть объектно-ориентированной и представлять собой БД.

Три класса характеристик:


  • Обязательные.

  • Необязательные.

  • Открытые — позволяют пользователю выбирать свойства.

СУБД

  • Долговременное хранение

  • Использование внешней памяти

  • Параллелизм

  • Восстановление

  • Нерегламентированные запросы


ОО характеристики

Поддержка сложных объектов.

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

Поддержка индивидуальности объектов.

Все объекты должны иметь уникальный идентификатор, который не зависит от значений их атрибутов.


Поддержка инкапсуляции.

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

Поддержка типов и классов.

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

(Термин «тип» более соответствует понятию абстрактного типа данных. В языках программирования переменная объявляется с указание ее типа. Компилятор может использовать эту информацию для проверки выполняемых с переменной операций на совместимость с ее типом, что позволяет гарантировать корректность программного обеспечения. С другой стороны класс является неким шаблоном для создания объектов и предоставляет методы, которые могут применяться к этим объектам. Таким образом, понятие «класс» в большей степени относится ко времени исполнения, чем ко времени компиляции.)

Поддержка наследования типов и классов от их предков.

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

Перегрузка в сочетание с полным связыванием.

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

Вычислительная полнота.

Язык манипулирования данными должен быть языком программирования общего назначения.

Набор типов данных должен быть расширяемым.

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


Необязательные:

  • Множественное наследование


  • Проверка типов

  • Распределение

  • Проектные транзакции

Открытые

  • Парадигмы программирования (процедурное, декларативное)

  • Система представления

  • Система типов

  • Однородность. Реализация — язык программирования — интерфейс.



4.Многомерная модель данных. OLAP. Хранилища данных.


5.Транзакции. OLTP.

6.Распределенные базы данных.

7.NoSQL.

8.Привилегии в базах данных.

СУБД обслуживает работу разных пользователей. У пользователей — разные привилегии (права). Механизм защиты данных —проверка пользователей на наличие

у них нужных привилегий!

Архитектура MySQL

Клиент-серверная!

Клиент — пользователь с прикладным приложением (mysql)

Сервер — СУБД с демоном (mysqld) и всеми данными

mysql -h localhost — подключение к серверу

Пользователи в MySQL

Локальные и внешние: root@localhost (127.0.0.1) user@foobar.ru (42.42.42.42)

root и user — имя пользователя

localhost и foobar.ru — хост, с которого можно подключаться (Хост бывает любым «%»)


Каждая запись о пользователе включает в себя: Имя; Хост; Пароль; Набор привилегий.

Привилегии: стандарт ISO(ISO/IEC 9075-2)

SELECT — право выбирать данные из таблицы;

INSERT — право вставлять в таблицу новые строки;

UPDATE — право изменять данные в таблице;

DELETE — право удалять строки из таблицы;

REFERENCES — право ссылаться на столбцы указанной таблицы в описаниях требований поддержки целостности данных;

USAGE — право использовать домены, проверки, наборы символов и трансляции.


UNDER — право на указанные типы структур

TRIGGER — триггеры

EXECUTE — процедуры

WITH GRANT OPTION — возможность передавать определенные права другим пользователям

GRANT OPTION — работа с привилегиями

Административные:

PROCESS — список процессов

SHUTDOWN — завершение

SUPER — параметры сервера, прерывание сессии


MySQL: управление пользователями

CREATE USER 'user'@'host'

IDENTIFIED BY 'password';

DROP USER 'user'@'host';

RENAME USER 'user' TO 'user2';

SET PASSWORD FOR 'user'@'host' = PASSWORD('newpassword');

GRANT priv_type [(cols)]

ON [object_type] `db_name`.`table_name`

TO 'user'@'host';

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

Кроме того, для упрощения в операторе GRANT можно указать ключевое слово ALL PRIVILEGES, что позволит предоставить указанному пользователю все шесть существующих привилегий без необходимости их перечисления.

REVOKE priv_type [(cols)]

ON [object_type] `db_name`.`table_name`

FROM 'user'@'host';

для отмены предоставленных пользователям посредством оператора GRANT привилегий используется оператор REVOKE.


9.Хранимые процедуры.

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

-Объект базы данных

-Набор SQL-инструкций

-Один раз задается и компилируется

-Хранится на сервере (в скомпилированном виде)


Выполнение в базе данных хранимых процедур вместо отдельных операторов SQL дает пользователю следующие преимущества:

необходимые операторы уже содержатся в базе данных;


хранимые процедуры могут вызывать другие хранимые процедуры и функции;

хранимые процедуры могут быть вызваны из прикладных программ других типов;

Производительность:

Компилируется один раз(хранится в удобном для компьютера виде)

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

Меньше сетевого трафика

Простота:

Более читаемый код

Компактность

Модульность (повторное использование, удобство дальнейшего сопровождения)

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

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

Безопасность:

Возможность ограничить доступ только к процедурам (аналогично представлениям)

Функциональность:

Использование возможностей языков программирования


Создание процедуры в MySQL

DELIMITER //

CREATE PROCEDURE `simpleproc`

(OUT `param1` INT)

BEGIN

SELECT COUNT(*) INTO `param1` FROM `t`;

END//

DELIMITER


CALL simpleproc(@foo);

SELECT @foo;


Переменные в MySQL

Системные (SHOW VARIABLES):

-Сессионные (SESSION) /локальные (LOCAL)

-Глобальные (GLOBAL)

Пользовательские:

-Внутри хранимых процедур(«простые»)

Используются только внутри блокатBEGIN .. END

Инициализация:тDECLARE `var` INT DEFAULT 0;

Присваивание: SET `var` = 42;

Доступны только внутри блокатBEGIN-END, т. е. самой процедуры

-Вне хранимых процедур


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

Обозначаются как @var

Инициализация не нужна: SET @newvar = 42; SELECT @newvar := 42;


CREATE PROCEDURE `simpleproc`

(OUT `param1` INT)

BEGIN

SELECT COUNT(*) INTO `param1` FROM `t`;

END

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

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

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


10.Триггеры.

Триггеры являются одной из разновидностей хранимых процедур.

Их исполнение происходит при выполнении для таблицы какого-либо оператора языка манипулирования данными (DML).

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

С помощью триггеров достигаются следующие цели:

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

выдача предупреждений, напоминающих о необходимости выполнения некоторых действий при обновлении таблицы, реализованном определенным образом;

накопление аудиторской информации посредством фиксации сведений о внесенных изменениях и тех лицах, которые их выполнили;

поддержка репликации.

Триггерные события состоят из вставки, удаления и обновления строк в таблице.


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

Время запуска триггера определяется с помощью ключевых слов BEFORE (Триггер запускается до выполнения связанных с ним событий) или AFTER (после их выполнения).

Создание триггера в MySQL

CREATE TRIGGER `trigger1`

BEFORE UPDATE ON `t_cur`

FOR EACH ROW

BEGIN

INSERT INTO `t_old` VALUES(OLD.`name`);

DELETE FROM `t_new` WHERE `name` =

NEW.`name`;

END;


Тем не менее следует упомянуть и о присущих триггеру недостатках:

сложность: при перемещении некоторых функций в базу данных усложняются задачи ее проектирования, реализации и администрирования;

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

Не принимают параметры — оперируют данными из OLD / NEW

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

В MySQL:

Только для таблиц

Не для системной БД (`mysql`)

Не активируются действиям над внешними ключами


Триггеры различают по типу команд, на которые они реагируют.

Существует три типа триггеров:

INSERT TRIGGER – запускаются при попытке вставки данных с помощью команды INSERT.

UPDATE TRIGGER – запускаются при попытке изменения данных с помощью команды UPDATE.

DELETE TRIGGER – запускаются при попытке удаления данных с помощью команды DELETE.

Внутри триггера не допускается выполнение ряда операций, таких, например, как:


-создание, изменение и удаление базы данных;

-восстановление резервной копии базы данных или журнала транзакций.


11.Репликация.

Репликация — механизм синхронизации содержимого нескольких копий объекта.

Репликация — это процесс, под которым понимается копирование данных из одного источника на множество других и наоборот.

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

Репликация: зачем?

Дополнительный уровень доступности: Отказоустойчивость Производительность


Репликация: синхронная

Если одна реплика обновляется(master), все другие реплики (slave) должны быть обновлены в той же транзакции

Всегда существует только одна версия данных(Логически это означает, что существует лишь одна версия данных.)

Реализация — триггеры (синхронная репликация реализуется с помощью триггерных процедур)

Недостаток — дополнительная Нагрузка (при выполнении всех транзакций, в которых обновляются какие-либо реплики)


Репликация: асинхронная

Изменения реплики распространяются на другие через некоторое время (задержка)

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

Реализация — журнал транзакций (реализуется посредством чтения журнала транзакций или постоянной очереди тех обновлений, которые подлежат распространению.)

Главное преимущество — скорость и постоянная доступность данных (дополнительные издержки репликации не связаны с транзакциями обновлений)

Главный недостаток — несогласованные данные


Репликация: «ленивая»(оптимистичная)

Не гарантируется постоянная согласованность данных

Дополнительная синхронизация производится в «свободное время



12.Резервное копирование. Восстановление после отказа.

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

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

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


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

Причины, способные вызвать отказы (типы отказов):

-Аварийное прекращение работы:

Аппаратная проблема

Программная проблема

-Ошибка в прикладной программе

-Уязвимость в безопасности

-Человеческий фактор

-Форс-мажор (извержение вулкана, апокалипсис, выборы, 42, …)


СУБД должна предоставлять следующие функции восстановления:

-механизм резервного копирования, предназначенный для периодического создания резервных копий базы данных;

-средства ведения журнала, в котором фиксируются текущее состояние транзакций и вносимые в базу данных изменения;

-функция создания контрольных точек, обеспечивающая перенос выполняемых в базе данных изменений во вторичную память с целью сделать их постоянными;


(Контрольная точка - момент синхронизации между базой данных и журналом регистрации транзакций. В этот момент все буфера системы принудительно записываются во вторичную память системы.)

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


Транзакции и восстановление

Транзакции представляют собой основную единицу восстановления в системах с базами данных.

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

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

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

-Если транзакция уже выдала команду фиксации, то для обеспечения устойчивости ее результатов диспетчер восстановления должен выполнить ее повторно (redo) (эту операцию часто называют накатом), чтобы восстановить все внесенные ею изменения.

-Если на момент отказа системы транзакция еще не была зафиксирована, диспетчер восстановления должен отменить (undo) любые ее результаты (выполнить их откат), что будет гарантировать соблюдение ее неразрывности


Методы восстановления

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

1.По журналу транзакций:

- Метод восстановления с использованием отложенного обновления

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

Обновления не заносятся в БД до команды транзакции зафиксировать выполненные изменения

Прекращение транзакции до фиксации не требует отмены изменений в БД)


- Метод восстановления с использованием немедленного обновления

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

Обновления заносятся в БД сразу после их выполнения

Требуется откат изменений до фиксации транзакции)


2. Метод теневого страничного обмена

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

Теневая таблица не изменяется по ходу транзакции и используется для восстановления текущей в случае сбоя

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

13.CASE-средства проектирования БД. Возможности проектирования БД, представляемые конкретными CASE-средствами (MySQL Workbench).


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


MySQL Query Browser — инструмент для создания выполнения и оптимизации запросов.

Интерфейс:

Query Toolbar (панель запросов).

Advanced Toolbar (дополнительная панель).

Result Area (область результатов).

Object Browser (обозреватель объектов).

Information Browser (обозреватель информации)

Использование

Откройте вкладку «Results», перенесите мышкой из обозревателя объектов требуемые вам объекты (базы данных, таблицы, функции, синтаксические выражения и т.д.) в панель запросов. Таким образом вы сконструируете запрос.

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

Для выполнения запроса нажмите кнопку «Выполнить» (Execute Query). Результат появится в области результатов.


MySQL Administrator — инструмент для администрирования сервера MySQL (конфигурация, мониторинг, управление пользователями и подключениями, резервное копирование и другое).

Интерфейс

Sidebar (панель).

Working Area (рабочая область).


МySQL Workbench — инструмент визуального проектирования баз данных. Позволяет проектировать, моделировать, создавать и поддерживать базы данных для MySQL.

Создание ER-диаграмм

Построение новой ER-диаграммы начинается с создания нового проекта (File -> New Project).

Далее добавляем к проекту новую ER-диаграмму («Add Diagram»). Создаем в ней новые элементы: Таблицы (T), представления (V) и другие. При создании объектов описываем их свойства. Например, для таблицы указываются ее атрибуты и свойства атрибутов. Проводим между таблицами связи от поля одной таблицы до внешнего ключа второй таблицы. Тип связи (много ко многим, одно к одному и другие) определяется формой стрелки примитива.

При проектировании можно использовать уже готовую базу данных из файла (SQL-дампа). В этом случае ER-диаграмма будет построена автоматически.

Работа с базами данных

Выбрав в окне объектов базу данных, мы можем производить над ними изменения. Для этого нужно выбрать соответствующее действие в разделе «Physical Schema» («Add Table», «Add View» и другие). После выбора действия откроется окно с вкладками описания действия. Например, для создания таблицы будет предложено ввести имя, тип таблицы, атрибуты таблицы, ключи таблицы, индексы, триггеры, добавить данные в таблицу и другое.