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

BDРуководство по проектированию реляционных баз данных

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

 

Руководство по проектированию баз данных.

 

1. Вступление.

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

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

Структурированный язык запросов (SQL).

База данных создается для хранения в ней информации и получения этой информации при необходимости. Это значит, что мы должны иметь возможность помещать, вставлять (INSERT) информацию в базу данных и мы хотим иметь возможность делать выборку информации из базы данных (SELECT).
Язык запросов к базам данных был придуман для этих целей и был назван
Структурированный язык запросовили SQL. Операции вставки данных (INSERT) и их выборки (SELECT) – части этого самого языка. Ниже приведен пример запроса на выборку данных и его результат.
SQL – большая тема для повествования и его рассмотрение выходит за рамки данного руководства. Данная статья строго сфокусирована на изложениипроцесса проектирования баз данных. Позднее, в отдельном руководстве, я расскажу об основах SQL.

Реляционная модель.

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

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

Примеры.

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

РСУБД.

РСУБД, которую я использовал для создания таблиц примеров – MySQL. MySQL – наиболее популярная РСУБД и она бесплатна.

Утилита для администрирования БД.

После установки MySQL вы получаете только интерфейс командной строки для взаимодействия с MySQL. Лично я предпочитаю графический интерфейс для управления моими базами данных. Я часто использую SQLyog. Это бесплатная утилита с графическим интерфейсом. Изображения таблиц в данном руководстве взяты оттуда.

Визуальное моделирование.

Существует отличное бесплатное приложение
MySQLWorkbench. Оно позволяет спроектировать вашу базу данных графически. Изображения диаграмм в руководстве сделаны в этой программе.


Проектирование независимо от РСУБД.


Важно знать, что хотя в данном руководстве и приведены примеры для
MySQL, проектирование баз данных независимо от РСУБД. Это значит, что информация применима к реляционным базам данных в общем, не только к MySQL. Вы можете применить знания из этого руководства к любым реляционным базам данных, подобным Mysql, Postgresql, MicrosoftAccess, MicrosoftSqlorOracle.

В следующей части я коротко расскажу об эволюции баз данных. Вы узнаете откуда взялись базы данных и реляционная модель данных.


2. История.


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



Так выглядели профессионалы в сфере информационных технологий в 70-е. (Слева внизу находится Билл Гейтс).

Текстовые файлы и сегодня все еще используются для хранения малых объемов простой информации.
Comma-SeparatedValues (CSV) — значения, разделённые запятыми, очень популярны и широко поддерживаются сегодня различным программным обеспечением и операционными системами. MicrosoftExcel – один из примеров программ, которые могут работать с CSV–файлами. Данные, сохраненные в таком файле могут быть считаны компьютерной программой.



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


Таблицы баз данных.


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



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

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


История реляционной модели.


Реляционная модель баз данных была изобретена в 70-х Эдгаром Коддом (
TedCodd), британским ученым. Он хотел преодолеть недостатки сетевой модели баз данных и иерархической модели. И он очень в этом преуспел. Реляционная модель баз данных сегодня всеобще принята и считается мощной моделью для эффективной организации данных.

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

Oracle– используется преимущественно для профессиональных, больших приложений.
MicrosoftSQLserver– РСУБД компании Microsoft. Доступна только для операционной системы Windows.
Mysql– очень популярная РСУБД с открытым исходным кодом. Широко используется как профессионалами, так и новичками. Что еще нужно?! Она бесплатна.
IBM– имеет ряд РСУБД, наиболее известна DB2.
MicrosoftAccess– РСУБД, которая используется в офисе и дома. На самом деле – это больше, чем просто база данных. MSAccess позволяет создавать базы данных с пользовательским интерфейсом.
В следующей части я расскажу кое-что о характеристиках реляционных баз данных.


3. Характеристики реляционных баз данных.


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


Использование ключей.


Каждая строка данных в таблице идентифицируется уникальным “ключом”, который называется первичным ключом. Зачастую, первичный ключ это автоматически увеличиваемое (автоинкрементное) число (1,2,3,4 и т.д). Данные в различных таблицах могут быть связаны вместе при использовании ключей. Значения первичного ключа одной таблицы могут быть добавлены в строки (записи) другой таблицы, тем самым, связывая эти записи вместе.

Используя структурированный язык запросов (
SQL), данные из разных таблиц, которые связаны ключом, могут быть выбраны за один раз. Для примера вы можете создать запрос, который выберет все заказы из таблицы заказов (orders), которые принадлежат пользователю с идентификатором (id) 3 (Mike) из таблицы пользователей (users). О ключах мы поговорим далее, в следующих частях.


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


Отсутствие избыточности данных.


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


Ограничение ввода.


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


Когда вы создаете таблицу базы данных вы предоставляете тип данных для каждого столбца. К примеру,
varchar – это тип данных для небольших фрагментов текста с максимальным количеством знаков, равным 255, а int – это числа.

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

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

— ввод адреса (текста) в поле, в котором вы ожидаете увидеть число
— ввод индекса региона с длинной этого самого индекса в сотню символов
— создание пользователей с одним и тем же именем
— создание пользователей с одним и тем же адресом электронной почты
— ввод веса (числа) в поле дня рождения (дата)


Поддержание целостности данных.


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


Назначение прав.


Большинство РСУБД предлагают настройку прав доступа, которая позволяет назначать определенные права определенным пользователям. Некоторые действия, которые могут быть позволены или запрещены пользователю:
SELECT (выборка), INSERT (вставка), DELETE (удаление), ALTER (изменение), CREATE (создание) и т.д. Это операции, которые могут быть выполнены с помощью структурированного языка запросов (SQL).


Структурированный язык запросов (SQL).


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

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




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


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

Как говорилось ранее, проектирование базы данных – это вопрос идентификации данных, их связи и помещение результатов решения данного вопроса на бумагу (или в компьютерную программу). Проектирование базы данных независимо от РСУБД, которую вы собираетесь использовать для ее создания.

4. ТАБЛИЦЫ И ПЕРВИЧНЫЕ КЛЮЧИ


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



В таблице имеются 6 уроков. Все 6 – разные, но для каждого урока значения одинаковых полей хранятся в таблице, а именно:
tutorial_id (идентификатор урока), title (заголовок)и category (категория). Tutorial_idпервичный ключтаблицы уроков. Первичный ключ – это значение, которое уникально для каждой записи в таблице.
В таблице клиентов ниже
customer_id – первичный ключ. В данном случае первичный ключ – также уникальное значение (число) для каждой записи.




Первичные ключи в повседневной жизни


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

Несколько примеров


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



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


Что характеризует первичный ключ? Характеристики первичного ключа.


Первичный ключ служит для идентификации записей.

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

Первичный ключ уникален.

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

|
first_name | last_name |
|
vasya |pupkin |
|
vasya |pupkin |

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

Id | first_name | last_name |
1 |
vasya |pupkin |
2 |
vasya |pupkin |

Теперь каждый Вася уникален.

Типы первичных ключей.

Обычно первичный ключ – числовое значение. Но он также может быть и любым другим типом данных. Не является обычной практикой использование строки в качестве первичного ключа (строка – фрагмент текста), но теоретически и практически это возможно.
Составные первичные ключи.
Часто первичный ключ состоит из одного поля, но он может быть и комбинацией нескольких столбцов, например, двух (трех, четырех…). Но вы помните, что первичный ключ всегда уникален, а значит нужно, чтобы комбинация
n-го количества полей, в данном случае 2-х, была уникальна. Подробнее об этом расскажу позднее.

Автонумерация.

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


5. СВЯЗЫВАНИЕ ТАБЛИЦ С ПОМОЩЬЮ ВНЕШНИХ КЛЮЧЕЙ


Когда я начинал разрабатывать базы данных я часто пытался сохранять информацию, которая казалась родственной, в одной таблице. Я мог, например, хранить информацию о заказах в таблице клиентов. Ведь заказы принадлежат клиентам, верно? Нет. Клиенты и заказы представляют собой отдельные сущности в базе данных. И тому и другому нужна своя собственная таблица. А записи в этих двух таблицах могут быть связаны для того, чтобы установить отношения между ними.
Проектирование базы данных – это решение двух вопросов:


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



Один-ко-многим.


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

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


Какую информацию мы будем хранить? Решаем первый вопрос.


Для начала мы определимся какую информацию о
заказахи оклиентахмы будем хранить. Чтобы это сделать мы должны задать себе вопрос:“Какие единичные блоки информации относятся к клиентам, а какие единичные блоки информации относятся к заказам?”

Проектируем таблицу клиентов.

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


  • customer_id (primary key) – идентификатор клиента
  • first_name — имя
  • last_name — отчество
  • address — адрес
  • zip_code – почтовый индекс
  • country — страна
  • birth_date – дата рождения
  • username – регистрационное имя пользователя (логин)
  • password – пароль



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


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

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


  • _date – дата и время заказа
  • customer – клиент, который сделал заказ



Ниже – пример таблицы в
SQLyog.


Проект таблицы. Поле
customer является ссылкой (внешним ключом) для поля customer_id в таблице клиентов.

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

Создание связи по внешнему ключу.

Вы можете задаться вопросом: “Каким образом я могу убедиться или как я могу увидеть, что поле
customer в таблице заказов ссылается на поле customer_id в таблице клиентов”. Ответ прост – вы не можете сделать этого потому, что я еще не показал вам как создать связь.
Ниже – окно
SQLyog с окном, которое я использовал для создания связи между таблицами.


Создание связи по внешнему ключу между таблицами заказов и клиентов.

В окне выше вы можете видеть, как поле
customer таблицы заказов слева связывается с первичным ключом (customer_id) таблицы клиентов справа.

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


Заказы связаны с клиентами через поле
customer, которое ссылается на таблицу клиентов.

На изображении вы видите, что клиент
 mary поместила три заказа, клиент pablo поместил один, а клиент john – ни одного.
Вы можете спросить: “А
чтоже именно заказали все эти люди?” Это хороший вопрос. Вы возможно ожидали увидеть заказанные товары в таблице заказов. Но это плохой пример проектирования. Как бы вы поместили множественные продукты в единственную запись?Товары– это отдельные сущности, которые должны храниться в отдельной таблице. И связь между таблицамизаказовитоваровбудет являться связью один-ко-многим. Я расскажу об этом далее.


6. СОЗДАНИЕ ДИАГРАММЫ СУЩНОСТЬ-СВЯЗЬ


Ранее вы узнали как записи из разных таблиц связываются друг с другом в реляционных базах данных. Перед созданием и связыванием таблиц важно, чтобы вы подумали о
сущностях, которые существуют в вашей системе (для которой вы создаете базу данных) и решили каким образом эти сущности бысвязывалисьдруг с другом. В проектировании баз данных сущности и их отношения обычно предоставляются вдиаграмме сущность-связь (англ. entity-relationshipdiagram, ERD). Данная диаграмма является результатом процесса проектирования базы данных.


Сущности.


Вы можете задаться вопросом, что же такое сущность. Нуу… это “вещь” в системе. Там. Моя Мама всегда хотела, чтобы я стал учителем потому, что я очень хорошо объясняю различные вещи.

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

Давайте возьмем интернет-магазин для примера. Интернет-магазин продает
товары.Товармог бы стать очевидной сущностью в системе интернет-магазина. Товарызаказываютсяклиентами. Вот мы с вами и увидели еще две очевидных сущности:заказыиклиенты.

Заказ оплачивается клиентом… это интересно. Мы собираемся создавать отдельную таблицу для платежей в базе данных нашего интернет-магазина? Возможно. Но разве платежи – это минимальный блок информации, который относится к заказам? Это тоже возможно.

Если вы не уверены, то просто подумайте о том, какую информацию о платежах вы хотите хранить. Возможно, вы захотите хранитьметод платежа
илидату платежа. Но это все еще минимальные блоки информации, которые могли бы относиться кзаказу. Можно изменить формулировки. Метод платежа — метод платежа заказа. Дата платежа – дата платежа заказа. Таким образом, я не вижу необходимости выноситьплатежив отдельную таблицу, хотя концептуально вы бы могли выделить платежи как сущность, т.к. вы могли бы рассматривать платежи как контейнер информации (метод платежа, дата платежа).

Давайте не будет слишком академичными.

Как вы видите, есть разница между сущностью и непосредственно таблицей в базе данных, т.е. это не одно и то же. Специалисты отрасли информационных технологий могут быть ОЧЕНЬ академичными и педантичными в этом вопросе. Я не такой специалист. Эта разница зависит от вашей точки зрения на ваши данные, вашу информацию. Если вы смотрите на моделирование данных с точки зрения программного обеспечения, то вы можете прийти к множеству сущностей, которые нельзя будет перенести напрямую в базу данных. В данном руководстве мы смотрим на данные строго с точки зрения баз данных и в нашем маленьком мире сущность – это таблица.


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

Как вы видите определение того, какие сущности имеет ваша система – это немного интеллектуальный процесс, который требует некоторого опыта и часто – это предмет для внесения изменений, пересмотров, раздумий, но, конечно, это не ракетостроение.


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


Связи.


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

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

 



7. Связь один-ко-многим.


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

Другой пример связи один-ко-многим – это связь, которая существует между матерью и ее детьми. Мать может иметь множество детей, но каждый ребенок может иметь только одну мать.

(Технически лучше говорить о женщине и ее детях вместо матери и ее детях потому, что, в контексте связи один-ко-многим, мать может иметь 0, 1 или множество потомков, но мать с 0 детей не может считаться матерью. Но давайте закроем на это глаза, хорошо?)

Когда одна запись в таблице А может быть связана с 0, 1 или множеством записей в таблице
B, вы имеете дело со связьюодин-ко-многим. В реляционной модели данных связь один-ко-многим использует две таблицы.


Схематическое представление связи один-ко-многим. Запись в таблице А имеет 0, 1 или множество ассоциированных ей записей в таблице
B.


Как опознать связь один-ко-многим?


Если у вас есть две сущности спросите себя:
1) Сколько объектов и
B могут относится к объекту A?
2) Сколько объектов из
A могут относиться к объекту из B?

Если на первый вопрос ответ –
множество, а на второй –один(или возможно, что ни одного), то вы имеете дело со связью один-ко-многим.


Примеры.


Некоторые примеры связи один-ко-многим:


  • Машина и ее части. Каждая часть машины единовременно принадлежит только одной машине, но машина может иметь множество частей.
  • Кинотеатры и экраны. В одном кинотеатре может быть множество экранов, но каждый экран принадлежит только одному кинотеатру.
  • Диаграмма сущность-связь и ее таблицы. Диаграмма может иметь больше, чем одну таблицу, но каждая из этих таблиц принадлежит только одной диаграмме.
  • Дома и улицы. На улице может быть несколько домов, но каждый дом принадлежит только одной улице.



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


8. Связь многие-ко-многим.


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

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

Обратите внимание, что при проектировании базы данных вы должны спросить себя не о том, существуют ли определенные связи в данный момент, а о том, возможно ли существование связей вообще, в перспективе. Если в настоящий момент все поставщики предоставляют множество видов пива, но каждый вид пива предоставляется только одним поставщиком, то вы можете подумать, что это связь один-ко-многим, но… Не торопитесь реализовывать связь один-ко-многим в этой ситуации. Существует высокая вероятность того, что в будущем два или более поставщиков будут поставлять один и тот же вид пива и когда это случится ваша база данных — со связью один-ко-многим между поставщиками и видами пива – не будет подготовлена к этому.


Создание связи многие-ко-многим.


Связь многие-ко-многим создается с помощью трех таблиц. Две таблицы – “источника” и одна соединительная таблица. Первичный ключ соединительной таблицы
A_Bсоставной. Она состоит из двух полей, двух внешних ключей, которые ссылаются на первичные ключи таблиц A и B.



Все первичные ключи должны быть уникальными. Это подразумевает и то, что комбинация полей
A и B должна быть уникальной в таблице A_B.

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


Таблицы “о пиве”.






Таблицы выше связывают поставщиков и пиво связью
многие-ко-многим, используя соединительную таблицу. Обратите внимание, что пиво 'GentseTripel' (157) поставляют HorecaImportNL (157, AC001) JansenHoreca (157, AB899) и PetersenDrankenhandel (157, AC009). И viceversa, PetersenDrankenhandel является поставщиком 3 видов пива из таблицы, а именно: GentseTripel (157, AC009), Uilenspiegel (158, AC009) и Jupiler (163, AC009).

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

Есть еще одна важная вещь на которую нужно знать. Связь многие-ко-многим состоит из
двух связей один-ко-многим. Обе таблицы: поставщики пива и пиво – имеют связь один-ко-многим с соединительной таблицей.


Другой пример связи многие-ко-многим: заказ билетов в отеле.


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


Соединительная таблица связи многие-ко-многим имеет дополнительные поля.

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

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


9. Связь один-к-одному.


В связи один-к-одному каждый блок сущности
A может быть ассоциирован с 0, 1 блоком сущности B. Наемный работник, например, обычно связан с одним офисом. Или пивной бренд может иметь только одну страну происхождения.


В одной таблице.


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


В отдельных таблицах.


В редких случаях связь один-к-одному моделируется используя две таблицы. Такой вариант иногда необходим, чтобы преодолеть ограничения РСУБД или с целью увеличения производительности (например, иногда — это вынесение поля с типом данных
blob в отдельную таблицу для ускорения поиска по родительской таблице). Или порой вы можете решить, что вы хотите разделить две сущности в разные таблицы в то время, как они все еще имеют связь один-к-одному. Но обычно наличие двух таблиц в связи один-к-одному считается дурной практикой.


Примеры связи один-к-одному.



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





Проект реляционной базы данных – это коллекция таблиц, которые перелинковываются (связываются) первичными и внешними ключами. Реляционная модель данных включает в себя ряд правил, которые помогают вам создать верные связи между таблицами. Эти правила называются “нормальными формами”. В следующих частях я покажу как нормализовать вашу базу данных.



Какой же вид связи вам нужен?


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

А если есть некие
данные, которые могу быть присвоены любому человеку, то имеем дело сосвязью многие-ко-многим. Например, есть таблица со списком людей и мы хотим хранить информацию о том, какие страны посетил каждый человек. В данном случае имеется две сущности: люди и страны. Любой человек может посетить любое количество стран равно, как и любая страна может быть посещена любым человеком. Т.е., в данном случае, страна не является уникальными данными для конкретного человека и может использоваться повторно.

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

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



10. Нормализация баз данных


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

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


  • В нормализованной структуре базы данных вы можете производить сложные выборки данных относительно простыми SQL-запросами.
  • Целостность данных. Нормализованная база данных позволяет надежно хранить данные.
  • Нормализацияпредотвращает появление избыточности хранимых данных. Данные всегда хранятся только в одном месте, что делает легким процесс вставки, обновления и удаления данных. Есть исключение из этого правила. Ключи, сами по себе, хранятся в нескольких местах потому, что они копируются как внешние ключи в другие таблицы.
  • Масштабируемость – это возможность системы справляться с будущим ростом. Для базы данных это значит, что она должна быть способна работать быстро, когда число пользователей и объемы данных возрастают. Масштабируемость – это очень важная характеристика любой модели базы данных и для РСУБД.



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


  • Упорядочивание данных в логические группы или наборы.
  • Нахождение связей между наборами данных. Вы уже видели примеры связей один-ко-многим и многие-ко-многим.
  • Минимизация избыточности данных.



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


11. Первая нормальная форма (1НФ)


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


Первичный ключ.


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

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


Атомарность.


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

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


Горизонтальное дублирование данных – плохая практика.

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


Множественные значения в одной ячейке.

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


Порядок записей не должен иметь значение.


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

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

В следующей части рассмотрим вторую нормальную форму (2НФ).


12. Вторая нормальная форма.


Для того, чтобы база данных была нормализована согласно второй нормальной форме, она должна быть нормализована согласно первой нормальной форме. Вторая нормальная форма связана с избыточностью данных.


Избыточность данных.


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

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


Дублирование данных среди записей в поле
store.

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

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

Колонка
 store содержит наименование магазина, в котором в настоящее время находится машина. Store – это очевидный пример избыточности данных и хороший кандидат для отдельной сущности, которая должна быть связана с таблицей автомобилейсвязью по внешнему ключу.
Ниже пример того, как бы вы моги смоделировать базу данных для автомобилей, избегая избыточности данных.



В примере выше таблица
 car имеет внешний ключ – ссылку на таблицы type и store. Столбец brand исчез потому, что на бренд есть неявная ссылка через таблицу type. Когда есть ссылка на type, есть ссылка и на brand, т.к. type принадлежит brand.

Избыточность данных была существенным образом устранена из нашей модели базы данных. Если вы достаточно придирчивы, то вы, возможно, еще не удовлетворены этим решением. А как насчет поля
 country_of_originв таблице brand?Покадубликатов нет потому, что есть только четыре бренда из разных стран. Внимательный разработчик базы данных должен выделить названия стран в отдельную таблицу country.

И даже сейчас вы не должны быть удовлетворены результатом потому, что вы также могли бы выделить поле
 color в отдельную таблицу.

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

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


13. Третья нормальная форма.


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


Транзитивные зависимости.


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



В этой таблице не все поля зависят исключительно от первичного ключа. Существует отдельная связь между полем
postal_code и полями города (city) и провинции (province). В Нидерландах оба значение: город и провинция – определяются почтовым кодом, индексом. Таким образом, нет необходимости хранить город и провинцию в клиентской таблице. Если вы знаете почтовый код, то вы уже знаете город и провинцию.

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

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

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



НДС (
valueaddedtax) – это процент, который добавляется к цене продукта (19% в данной таблице). Это означает, что значение total_ex_vat может быть вычислено из значения total_inc_vat и viceversa. Вы должны хранить в таблице одно из этих значений, но не оба сразу. Вы должны возложить задачу вычисления total_inc_vat из total_ex_vat или наоборот на программу, которая использует базу данных.

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

Третья нормальная форма не всегда используется при проектировании баз данных. Когда разрабатываете базу данных вы всегда должны сравнивать преимущества от более высокой нормальной формы в сравнении с объемом работ, которые требуются для применения третьей нормальной формы и поддержания данных в таком состоянии. В случае с клиентской таблицей лично я бы предпочел не нормализовать таблицу до третьей нормальной формы. В последнем примере с НДС я бы использовал третью нормальную форму.
Хранение данных, воспроизводимых из существующих, обычно плохая идея.



14. Другой пример: база данных интернет-магазина.


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


Система интернет-магазина.


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


  • Отображение товаров
  • Классификация товаров
  • Регистрация клиентов
  • Добавление товаров в корзину покупок
  • Отображение содержимого корзины покупок
  • Оформление заказов посетителями
  • И т.д.




Определяем сущности и отношения.


Из списка задач мы можем вывести сущности, которые имеют важные роли в нашей системе.
Товары,категории,клиентыизаказы– сущности, которые можно найти почти в каждой базе данных интернет-магазина. В данном примере я покажу вам модель, содержащую только следующие сущности:клиент,заказитовар. Определившись с сущностями, мы можем подумать над связями между ними.


  • Междузаказомитоваромсуществует связьмногие-ко-многим. Каждый заказ содержит 1 или более товаров и каждый товар может быть связан с 0, 1 или большим количеством заказов. Связь многие-ко-многим создается с помощью трех таблиц. Две таблицы – источники данных ( — заказ и products — товары) и одна – соединительная (OrderProducts), что вы и можете увидеть на картинке ниже. Обратите внимание на то, что и заказы и товары имеют связь один-ко-многим с соединительной таблицей. Вместе они образуют связь многие-ко-многим между заказами и товарами.
  • Клиенты и заказы имеют связь один-ко-многим. Каждая запись о клиенте может быть связана с множественными записями о заказах (заказами) и наоборот, каждая запись о заказе (конкретный заказ) может быть связана только с одной записью о клиенте.




Данная таблица является простым примером. “Настоящая” таблица клиентов, конечно, содержит больше информации (адрес, город и т.д.)

Некоторые замечания о данной модели.


Таблица заказов (order)



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

Количество заказов.

Если вы задались вопросом, а можете ли вы добавить, например, поле количества заказов (
order_quantity), то ответ – нет. Эти данные могут бытьполучены из существующих данных. Общее количество товаров в заказе (order_quantity) может быть получено из таблицы OrderProduct. Запрос, который находит количество товаров в заказе может быть легко сформирован с помощью SQL.

Тип платежа.

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

Общая сумма заказа.

Еще одно поле, которое вы можете (а возможно и должны) добавить в таблицу
order – это поле для общей суммы заказа. Но вы можете подумать, что эти данные мы можем получить из существующих. Вы ведь можете сложить стоимости всех товаров заказа? Да. И нет. Цена товара – это величина изменяемая. Поэтому когда вы подсчитаете общую стоимость заказа, сложив стоимости каждого его товара, а владелец магазина удвоит стоимость одного из товаров в заказе, то и общие стоимости всех уже выполненных заказов тоже изменятся. Иначе говоря, если высчитывать общую стоимость заказа при просмотре, а цены на товары могут меняться, то при этом самом просмотре истории может возникнуть такая ситуация, когда количество денег, которые вы заплатили за весь заказ, будет меняться. Вот почему лучше высчитывать общую стоимость в момент оформления заказа и хранить ее в таблице order.

Хранение истории цен на товары.

Говоря про историю, можно предположить, что вам может понадобится сохранять и историю цен на каждый товар. В этом случае вы бы могли посмотреть на дату заказа, сделать запрос к таблице
price_history (история цен) и получить стоимость товара на дату оформления заказа. В данном случае вам не пришлось бы хранить общую стоимость заказа в таблице order. Я полагаю, что большинство интернет-магазинов сохраняют общую стоимость товаров заказа и не хранят историю цен на эти товары. Но, если говорить про вас, то разработчик вы и вам решать делать это или нет.


Таблица товаров.


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


15. Вывод и дальнейшее чтение.


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


Куда двигаться дальше?


Если вы хотите разработать свою базу данных, то обязательно познакомьтесь с
Mysqlworkbench. Это отличная утилита для создания диаграмм сущность-связь и не только. Я широко использую ее в своей работе разработчика программного обеспечения, даже если в работе не используется РСУБД Mysql.

Другим логичным шагом после прочтения данного руководства будет ознакомление со структурированным языком запросов (
SQL). Моделирование баз данных с помощью Mysqlworkbench или управление ими с помощью Sqlyog – это все здорово, но… если вы действительно хотите понимать как пользоваться базами данных, то SQL – это навык без которого у вас этого не получится. У W3Schools имеются неплохиеуроки по SQL, с которых вы можете начать.