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

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

Основы данных

Представление данных

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

JSON (JavaScript Object Notation) - это текстовый формат обмена данными, основанный на JavaScript. И пусть вас не обманывает JavaScript в названии. Формат JSON, хотя и произошел от этого языка программирования, полностью независим от него и может использоваться где угодно.

Давайте посмотрим, из чего состоит объект JSON и как он записывается.

Все полученные вами данные были заключены в фигурные скобки "{}". Они всегда располагаются в начале и в конце объекта JSON.

Сам объект состоит из набора записей, которые представляют собой пары "Ключ : Значение" и отделяются друг от друга запятыми ",".

Ключ - это имя самой записи, заключенное в кавычки "". Примеры: "название", "значение", "регион", "адрес". Это может быть любое слово, главное при разработке убедиться, что это значение понятно.

Значения могут быть разных типов. Давайте рассмотрим их все.

  1. Строка. Содержит текстовую информацию, набор символов в стандарте Unicode. Строки заключаются в кавычки "".
  2. Число. Может быть как целым числом, так и с плавающей запятой. Записывается как есть, заключать в кавычки не обязательно.
  3. Булево. Одно из двух значений. Либо истина, либо ложь. Как и число, записывается без кавычек.
  4. Массив. Упорядоченный набор элементов. Каждый элемент может быть любого типа. Массив заключается в квадратные скобки "[]", а его элементы разделяются запятыми.
  5. Объект. JSON-значение может быть другим JSON-объектом. К нему применяются те же правила, что и к корневому объекту. Он также заключен в фигурные скобки и содержит свой собственный набор записей.

Посмотрите на данные, которые вы получили в первых модулях, с учетом этой информации. Выделите компоненты JSON, определите, к какому типу относятся полученные значения.

Хранение данных

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

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

Для управления данными с реляционной моделью СУБД использует язык SQL.

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

Существует множество различных реляционных СУБД. Среди наиболее распространенных - Oracle, MySQL, MS SQL, PostgreSQL. Кстати, AppMaster использует PostgreSQL, а это значит, что он использует современную передовую СУБД, которая работает в огромном количестве различных организаций, а также является свободным программным обеспечением (то есть за ее использование не нужно платить дополнительные деньги).

Вы заметили присутствие аббревиатуры SQL почти в каждом названии СУБД? Вообще-то, альтернативное название реляционной базы данных - база данных SQL.

Однако существует и альтернативный подход. Нереляционные базы данных, или NoSQL. Стоит отметить, что No в данном случае - это не отрицание "нет", а аббревиатура от Not only. То есть "не только SQL".

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

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

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

Примерами NoSQL СУБД являются MongoDB и Redis.

Проектирование базы данных

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

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

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

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

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

  1. ID (целое число) - уникальный идентификатор, первичный ключ. Он автоматически создается для каждой новой записи в таблице и предназначен для обеспечения отсутствия дубликатов. Именно по ID можно однозначно идентифицировать запись в таблице. Его значение начинается с 1 и автоматически увеличивается на 1 для каждой новой записи.
  2. CreatedAt (datetime) - время создания записи в таблице.
  3. UpdatedAt (datetime) - время последнего изменения записи.
  4. DeletedAt (datetime) - время, когда запись была удалена. Разумеется, только в том случае, если было использовано мягкое удаление. То есть такое удаление, когда запись только помечается как удаленная и фильтруется по запросам на доступ к ней, но при этом физически остается в таблице. Это отличается от массового удаления, при котором данные фактически удаляются полностью.

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

Выбор типа поля не должен стать проблемой. Для названия подойдет String, а для информационного описания - Text.


Кроме того, доступны еще четыре переключателя:

  1. Множественные значения (массив) - используйте массивы вместо одиночных записей.
  2. Not null - указанное поле не может быть пустым, оно всегда должно содержать данные.
  3. Уникальный - значение поля должно быть уникальным, в данной модели не может быть двух записей, у которых значения этого поля одинаковы.
  4. Index - указывает, что для данного поля будет создан специальный индекс, чтобы ускорить поиск.

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

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

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

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


Существует 3 различных типа связей:

  1. Один-к-одному (имеет один). Каждая запись в таблице сопоставляется с одной записью из связанной таблицы (это верно и в обратном направлении). Простой пример - человек и его паспорт. Мы всегда можем быть уверены, что эта связь уникальна. У паспорта может быть только один владелец, и у каждого человека может быть только один действующий паспорт.
  2. Один-ко-многим (имеет многих). Каждая запись в одной таблице может иметь много записей в другой таблице. Подобным примером является наша база данных. У страны может быть много разных городов, но каждый город может принадлежать только одной стране. Именно эту связь мы и будем устанавливать.
  3. Многие-ко-многим. Связь, в которой несколько записей из одной таблицы могут соответствовать нескольким записям из другой. Простой пример - связь между учителями и учениками. Каждый учитель может обучать многих учеников, так же как и каждый ученик может учиться у многих разных учителей.

Домашнее задание

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

  • Необходимо предусмотреть наличие товаров с карточками их описания, различных категорий товаров, информации о заказах и о клиентах.
  • Наполните таблицы полями различных типов (используйте не менее 5 типов).
  • Установите связи между таблицами. Используйте все 3 типа связей.