Реляционные базы данных

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

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

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

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

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

Допустим, есть таблица пользователей. В ней могут быть столбцы user_id, first_name, email, city. Это свойства пользователя. А каждая строка — один конкретный пользователь (объект) со своими значениями (свойствами) в этих столбцах.

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

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

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

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

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

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

4. SQL
Из сказанного выше можно сделать вывод: данные компаний хранятся в базах данных. Внутри реляционная БД состоит из таблиц, и, как правило, в каждой таблице хранится информация об одной сущности. Это может быть таблица клиентов, заказов, товаров, сотрудников и так далее. Чтобы всем этим управлять (создавать, изменять, использовать), нужна СУБД. Дальше напрашивается очевидный вопрос: а как управлять самой СУБД? Что нужно ей сообщить, чтобы она сделала то, что нам нужно? Для этого необходимо знание специального языка для общения с БД, который называется SQL.

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

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

Смысл этого запроса такой: сходи в таблицу users, возьми оттуда несколько столбцов и покажи результат. Даже на этом уровне видно, что SQL — это способ задавать базе точные вопросы.

5. Как приложение добирается до базы данных
Если ваша работа связана с IT-системами, то вам часто будет необходимо писать SQL-запросы своими руками. Этому мы и будем обучаться. Выше мы уже читали, что почти любой сайт взаимодействует с базой данных. Это действительно так: на экране монитора мы видим информацию из БД, например, когда выбираем себе товар к покупке на маркетплейсе. Далее мы оплачиваем его и через несколько дней получаем. Это говорит о том, что наши действия, совершённые на сайте, вносят изменения в БД. Но как это возможно, ведь для этого нужно составить правильный SQL-запрос в СУБД. Разве обычный пользователь сайта должен знать SQL, чтобы заказать себе товар? Ответ: нет. За него этот запрос автоматически собирается бизнес-логикой, на которой написано приложение, то есть кодом.

Сначала действие уходит из интерфейса сайта в приложение. Обычно это происходит через HTTP-запрос: браузер отправляет данные формы на бэкенд. Бэкенд — это код, в котором живёт основная логика сайта. Он принимает запрос, проверяет данные, решает, что именно нужно сделать, и уже после этого формирует обращение к СУБД.

На этом шаге бэкенд переводит бизнес-команду в SQL. Он не идёт в таблицы БД сам. Он собирает SQL-команду, например команду на добавление нового пользователя, и отправляет её в PostgreSQL. PostgreSQL как СУБД принимает этот запрос, выполняет его над таблицами в БД и возвращает результат обратно в бэкенд. Бэкенд на основе этого результата формирует HTTP-ответ, а интерфейс показывает человеку итог: регистрация прошла успешно, данные сохранены, можно входить в систему.

Если коротко, путь такой: человек действует в интерфейсе, интерфейс отправляет запрос в бэкенд, бэкенд переводит бизнес-команду в SQL, СУБД выполняет SQL над таблицами, а потом вся цепочка идёт назад уже с готовым результатом.

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

Основные таблицы, с которыми мы будем работать дальше:

• users — пользователи;
• products — товары;
• orders — заказы;
• order_items — строки состава заказа;
• workers — сотрудники;
• departments — отделы.

Посмотрим еще на один SQL запрос, который обращается к таблице заказов:

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

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