Схема Базы данных для бэкендеров

Привет!

Возможно, вы столкнулись с ситуацией, когда бэкендер спрашивает: “А где схема базы данных?” или “Нужна ER-диаграмма”. Давайте разберемся, что это такое и зачем это нужно - без технического жаргона :)

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

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

А вот тут и появляется термин ER-диаграмма (Entity-Relationship diagram, диаграмма сущностей и связей). Это визуальная схема, которая показывает, как будут храниться данные вашего продукта. Она описывает структуру базы данных - что, где и как будет лежать.

Есть классическое представление БД - это набор таблиц. Да-да, прямо как в Excel, только с особыми правилами. Каждая таблица - это отдельная сущность (Entity). Например, таблица “Пользователи”, таблица “Заказы”, таблица “Товары”. И между этими таблицами есть связи (Relationship, отношения). Например, “Пользователь создает Заказ”, “Заказ содержит Товары”.

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

• Строка (string, varchar) - для текста, например, “Иван Иванов”
• Число (integer, int) - для целых чисел, например, возраст 25
• Дробное число (float, decimal) - для цен, например, 1599.99
• Дата и время (datetime) - для временных меток, например, “2024-01-13 15:30:00”
• Булево значение (boolean) - для да/нет, например, “подписан на рассылку: да”
• Текст (text) - для больших текстов, например, описание товара
• Бинарные файлы (blob) - для файлов и изображений

Дальше - больше. У каждой колонки есть дополнительные свойства:

• Обязательность заполнения (можно ли оставить пустым?)
• Значение по умолчанию (что подставлять, если не указано?)
• Уникальность (может ли быть два одинаковых значения?)
• Первичный ключ (уникальный идентификатор записи)

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

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

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

А как это описать для бэкендера? Просто схемы недостаточно - нужна детальная спецификация. Я дополнительно прикладывал таблицу с описанием всех деталей по каждому полю:

В этой таблице указано:

• Название таблицы
• Название колонки
• Тип данных (string, integer и т.д.)
• Длина поля (например, имя - максимум 255 символов)
• Обязательность заполнения
• Связи с другими таблицами
• Комментарии и примечания

Как создать ER-диаграмму? Есть несколько способов:

1. Нарисовать от руки - для быстрого наброска на встрече
2. Использовать draw.io (бесплатно, онлайн) - самый популярный инструмент для диаграмм
3. Использовать специализированные инструменты - DbDesigner, MySQL Workbench, pgModeler (для конкретных типов БД)
4. Попросить бэкендера - часто они сами рисуют схему и согласовывают с вами

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

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

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

Пример диалога с бэкендером:

Вы: “Нам нужно хранить информацию о пользователях и их заказах”

Бэкендер: “Окей, какие поля нужны в пользователе?”

Вы: “Имя, фамилия, email, телефон. Email обязателен, остальное можно не заполнять”

Бэкендер: “Понял. А в заказе?”

Вы: “Номер заказа, дата создания, статус, общая сумма, и список товаров”

Бэкендер: “Хорошо, тогда у нас будет три таблицы: Users, Orders, OrderItems. Нарисую схему и покажу”

Вот и весь процесс :)

Если хотите углубиться в детали, можно почитать про ER-диаграммы - начните с Wikipedia, а дальше уже ищите детали, если вы с этим сталкиваетесь в своих проектах.

Надеюсь, теперь понятнее, что такое схема БД и зачем она нужна бэкендерам :)

p.s. Когда бэкендер в следующий раз скажет “нужна ER-диаграмма”, вы уже не растеряетесь - просто обсудите с ним, какие данные нужно хранить и как они связаны между собой!