Для того чтобы можно было работать с данными на русском языке, нужно использовать кодировку UTF8. Кодировка сама по себе отвечает за набор символов. А вот правила сравнения этих символов задаются сопоставлением.

Что такое правила сравнения? Ну, например, при одном и том же наборе символов можно различать большие и маленькие буквы, а можно не различать. Это уже будут разные правила сопоставления. Есть и другие более тонкие отличия в этих правилах.

Нам нужно указать сопоставление utf8_bin. Есть еще ряд сопоставлений, которые можно использовать, но остановимся на utf8_bin.

Обратите внимание на нижнюю часть окна. Мы вписали имя и сопоставление, а в нижней части сформировалась команда

CREATE DATABASE `project_manager`

Это и есть обещанный интерактив. Если бы мы не использовали менеджер HeidiSQL, то команду пришлось бы набирать руками в командной строке.

Жмем OK и обязательно обновляем сеанс. Для этого нужно выделить левой кнопкой мыши сеанс и нажать либо F5, либо кнопку на панели инструментов (рис.1.9).

Рис.1.9 – База данных в дереве сеанса

После этого база данных project_manager отобразится в дереве сеанса.

Кстати, проверим сопоставление. Перейдем в правой части интерфейса на вкладку «Хост» и увидим, что напротив нашей базы данных установлено сопоставление utf8_bin (рис.1.10). Если в какой-то базе данных некорректно отображаются русские буквы, то именно здесь нужно проверять сопоставление. Например, сопоставление latin1_swedish_ci, которое мы видим у базы данных «test», не отображает кириллицу вообще.

Рис.1.10 – Базы данных и их соспоставление

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

Рис.1.11 – Редактирование базы

Как создать таблицу?

Для создания таблицы выделяем нужную базу данных и в контекстном меню правой кнопки мыши выбираем команды «Создать» и «Таблица» (рис.1.12)

Рис.1.12 – Создание таблицы

Прежде всего таблице нужно задать имя. В нашем случае это будет «projects» (рис.1.13).

Рис.1.13 – Создание таблицы

Далее нажатием на кнопку «Добавить» добавляем в таблицу поля. У нас их будет два: projectID и projectName (рис.1.13).

Поле projectID будет иметь тип INT. То есть оно может содержать целые числа. С помощью контекстного меню для поля projectID зададим свойство «Primary», как показано на рис.1.14. Это означает, что данное поле будет первичным ключом таблицы.

Рис.1.14 – Задание первичного ключа

Зададим этому полю также свойство «Беззнаковое» и свойство AUTO_INCREMENT (рис.1.15).

Рис.1.15 – Свойства первичного ключа

Свойство «Беззнаковое» нужно, чтобы в нумерации были только положительные числа, а автоинкремент позволит автоматически увеличивать значение поля на 1 при добавлении новой записи.

Для поля projectName зададим тип данных varchar c длиной значения 50 (рис.1.16). Этот тип данных подходит для текстовых строк. Строка типа varchar (50) будет занимать память в соответствии со своей реальной длиной, но эта длина не может превышать 50 символов.

Рис.1.16 – Поле с типом varchar (50)

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

На рис.1.17 подсказка сообщает нам, что тип SMALLINT может содержать либо числа от -32768 до +32767, либо, если мы объявим поле беззнаковым и тем самым отсечем отрицательные числа, от 0 до 65535.

Рис.1.17 – Типы данных

Кстати, обратите внимание, что для строковых типов автоматически указывается сопоставление. И оно именно такое, как мы выбрали при создании базы данных – utf8_bin (рис.1.18).

Иногда бывает нужно задать для отдельного поля сопоставление, отличное от того, которое задано на уровне всей базы. Это можно сделать через свойство «Сопоставление» (рис.1.18) путем выбора из выпадающего списка.

Рис.1.18 -Сопоставление отдельного поля

Жмем «Сохранить». Таблица создана.

Теперь перенесем взгляд в нижнее окно интерфейса (рис.1.19). Там все время что-то происходило, пока мы работали! Потому что там наши действия дублируются SQL-кодом.

Рис.1.19 – SQL-код

Например, когда мы нажали «Сохранить», то появился код

CREATE TABLE `projects` (
`projectID` INT UNSIGNED NOT NULL AUTO_INCREMENT,
`projectName` VARCHAR (50) NULL,
PRIMARY KEY (`projectID`)
)
COLLATE=’utf8_bin’;

Этот же код можно увидеть теперь на вкладке «Код CREATE» (рис.1.20).

Рис.1.20 – Код CREATE

Это инструкция «СREATE TABLE», которая создает таблицу. В доисторические времена, когда не было менеджеров баз данных, нужно было вписывать весь этот SQL-код руками в командную строку. И, естественно, синтаксис инструкции CREATE требовалось знать наизусть.

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

Добавление данных в таблицу

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

Рис. 1.21 – Вкладка «Данные»

Здесь новую строку в таблицу можно добавить либо кнопкой, либо клавишей Insert (рис.1.22).

Рис.1.22 – Добавление данных

Пусть в нашей таблице хранится список проектов. Добавим следующие записи (рис.1.23).

Рис.1.23 – Добавление данных

Удалить выбранную строку можно кнопкой (рис.1.24).

Рис.1.24 – Удаление строки

Самостоятельная работа №1

– Создайте в базе данных project_manager таблицу employee (сотрудники) со следующими характеристиками (рис.1.25):

Рис.1.25 – Поля таблицы employees

– Заполните созданную таблицу данными (рис.1.26)

Рис.1.26 – Данные таблицы

Внешние ключи

Теперь у нас есть таблица «projects», которая содержит список проектов, и таблица «employees», которая содержит список сотрудников. Требуется распределить сотрудников по проектам с условием, что один сотрудник может работать в нескольких проектах.

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

В данном случае требуется создать ассоциирующую таблицу, которая будет содержать первичные ключи двух исходных таблиц в качестве внешних. Создадим таблицу «job» с первичным ключом jobID и полем employeeID (рис.1.27).

Рис.1.27 – Таблица job

Теперь сделаем из поля employeeID внешний ключ. Для этого перейдем на вкладку «Внешние ключи» и добавим новый внешний ключ (рис.1.28).

Рис.1.28 – Внешний ключ

Далее нужно показать на какую таблицу внешний ключ ссылается. Для этого нужно заполнить три свойства внешнего ключа (рис.1.29).

Рис.1.29 – Формирование внешнго ключа

Здесь мы указываем поле таблицы «job», которое будет внешним ключом (employeeID), потом указываем на какую таблицу оно ссылается («employees») и, наконец, на какое конкретно поле таблицы «employees» оно ссылается (employeeID). Внешний ключ сформирован.

Самостоятельная работа №2

1. Добавьте в таблицу «job» еще один внешний ключ – projectID, который ссылается на projectID в таблице «projects».

2. Добавьте еще два поля.

dateBegin – дата начала работы в проекте с типом DATE;

dateEnd – дата окончания работы в проекте с типом DATE.

Для обоих полей допускается значение NULL.

3. Добавьте поле payment – оплата за участие в проекте. Тип данных – MEDIUMINT, NULL не допускается, значение по умолчанию -0 (рис.1.30).

Рис.1.30 – Окончательная структура таблицы «job»

Ограничения целостности

Заполним базу данных в соответствии с рис. 1.31.

Рис.1.31 – Заполненные таблицы

Говоря простым языком, целостность данных, это, когда проекту с определенным кодом в таблице «job» находится соответствие в таблице «projects», а сотруднику в таблице «job» находится соответствие в таблице «employees».

Если бы в таблице «job» значился сотрудник с кодом 5, которого нет в таблице «employees», то это было бы нарушением целостности данных.

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

При попытке вставить в поле projectID таблицы «job» несуществующий код проекта, СУБД покажет диагностическое сообщение об ошибке (рис.1.32).

Рис.1.32 – Диагностическое сообщение о нарушении целостности данных

Вообще все диагностические сообщения обязательно нужно читать, переводить и понимать, а не закрывать и пытаться угадать, в чем проблема. Данное сообщение говорит нам, что «запись невозможно добавить или отредактировать, так как нарушается ограничение внешнего ключа». Конечно, именно такую ошибку мы тут допустили умышленно: попытались вставить проект с кодом 2022, хотя существуют только проекты с кодами 1, 2, 3, 4.

Также возможна обратная ситуация. Сотрудника с кодом 1 (Иванова Ивана) решили по каким-то причинам удалить из системы. Но сотрудник уже записан как участник проекта с кодом 1. Как поступить с записью в таблице «job», которая связана с этим сотрудником? Для ответа на этот вопрос есть свойство «ПриDELETE» в настройке внешнего ключа (рис.1.33).

Рис.1.33 – Ограничения при удалении записи

При удалении сотрудника возможны следующие действия со связанной записью:

RESTRICT – ОГРАНИЧИТЬ. В этом случае при попытке удаления сотрудника из таблицы employees появится вот такое диагностическое сообщение:

Рис.1.34 – Ограничение RESTRICT

Сообщение говорит нам, что «невозможно удалить или изменить родительскую запись, так как нарушаются ограничения внешнего ключа». Запись с кодом 1 из таблицы «employees» является родительской по отношению к записи в таблице «job». Данное сообщение просто предупреждает нас о том, что удаление выполнить невозможно. Мы можем принять одно из двух решений:

– Сначала удалить связанную дочернюю запись в таблице «job», а уже потом выполнить удаление в таблице «employee». Тогда удаление выполнится.

– После диагностического сообщения понять, что попытка удаления была ошибочной и запись вообще не нужно удалять.