С вами снова бизнес-аналитик Юлия Чугунова. На этот раз говорим про логическую модель данных. Ту самая, на которой обычно всё и начинает идти не по плану. Если вы уже сталкивались с таблицами, которые «вроде бы работают, но никто не понимает как», то вам сюда. Объясняем почти на пальцах и с примерами. Вы поймете, даже если все кажется сложным! Полезно аналитикам, архитекторам, всем, кто проектирует под что-то большее, чем «лишь бы завелось».
Наш герой продолжает свое путешествие. Он уже научился слышать и фиксировать данные своими длинными лапами, а его гибкий позвоночник помогает собирать разрозненные фрагменты в единую структуру. Хотя у него еще нет глаз, его «когти» и «чуйка» подсказывают: в системе ничего не должно теряться, дублироваться или пересекаться без необходимости.
Пора перейти к логической модели – следующему шагу после концептуальной.
Что такое логическая модель?
На этапе логической модели мы уточняем и структурируем результаты концептуального анализа: переводим бизнес-сущности в таблицы, добавляем ключи и связи. Мы:
• определяем, какие сущности (таблицы) будут в базе;
• какие атрибуты (поля) входят в каждую таблицу;
• какие поля являются ключами – первичными (PK) и внешними (FK);
• как таблицы связаны между собой.
Это помогает навести порядок еще до технической реализации и избежать типичных архитектурных ошибок: дублирования данных, пропущенных связей, нарушенной целостности.
Примечание по стилю именования полей:
В этой статье для наглядности используются полные имена полей: customer_id, order_id, jam_id и другие. Такой стиль позволяет сразу понять, к какой сущности относится поле, особенно если оно участвует в связях между таблицами.
В некоторых проектах (особенно при использовании ORM) может применяться сокращенный стиль – например, id внутри каждой сущности. Такой подход тоже допустим, если команда придерживается единого и осознанного соглашения об именовании. Главное, чтобы названия были читаемыми, понятными и однозначными для всех участников проекта.
Основные сущности, атрибуты и ключи проекта
Примечание. Таблица order_line – это промежуточная сущность, описывающая, какие джемы и в каком количестве входят в заказ. Она реализует связь «многие ко многим» между заказами и джемами.
Особенности логической модели
- Типы данных указаны в обобщенном виде – строка, число, дата — без технических подробностей (например,
VARCHAR(100)– строка до 100 символов, илиDECIMAL(8,2)– число с двумя знаками после запятой). Это будет уточнено на этапе физической модели. - Ключи помечены явно: первичные (PK) и внешние (FK), с указанием направлений связей.
- Связи между таблицами уже отражены, но ограничения уровня СУБД (например,
NOT NULL– поле обязательно для заполнения,UNIQUE– значение должно быть уникальным,CHECK– проверка условия на значение) еще не задаются – это будет позже.
Почему это важно?
- Мы убеждаемся, что все сущности учтены, и ничего не забыто.
- Видим, как объекты системы связаны между собой, и можем проверить логику этих связей.
- Можем заранее обнаружить избыточность, дублирование или пропущенные связи.
- И просто быстрее схватываем структуру — иногда один взгляд на таблицу говорит больше, чем страницы текста.
Что дальше? Следующий шаг – визуализация этой структуры через ER-диаграмму (Entity-Relationship diagram). Это не просто иллюстрация, а рабочий инструмент, с которым удобно обсуждать структуру с разработчиками, архитекторами и заказчиком. Он позволяет согласовать модель на раннем этапе, избежать недопонимания и начать реализацию с четким архитектурным планом.
Как строится ER-диаграмма
1. Сущности (Entities)
Каждая таблица представляется прямоугольником с названием.
Примеры сущностей:
Customer, Jam, Order, Order_Line,
Address, Status, Payment_Method.
2. Атрибуты (Attributes)
Внутри каждой сущности указываются ее поля:
- Первичный ключ (PK) – уникальный идентификатор записи. Его принято выделять жирным, подчеркиванием или специальной меткой (PK).
- Внешние ключи (FK) – поля, ссылающиеся на первичные ключи других таблиц. Они обозначаются как FK и указывают, с какой другой сущностью установлена связь.
Остальные поля указываются обычным текстом.
3. Связи (Relationships)
Связи между сущностями отображаются линиями с указанием направления и кардинальности.
Важно указывать:
- Тип связи:
- 1:1 один к одному (редко встречается).
- 1:N один ко многим (самый распространенный случай).
- N:M многие ко многим (реализуется через промежуточную таблицу).
- Кардинальность обозначается рядом с линиями (например, 1..1, 0..N, 1..N). В сокращенной форме часто используют просто
1иN, без уточнения 0 или 1 – этого достаточно для чтения общей структуры. - Связь должна быть подкреплена внешним ключом, это отражается и на схеме, и в SQL.
Тренды и фишки из мира IT,
экспертные статьи и всё о тестировании.
4. Роль внешних ключей (FK) в диаграмме
FK – основа любой связи в ER-диаграмме. Они:
- создают ссылочную целостность между таблицами;
- определяют направление связи;
- помогают визуализировать, как одна сущность «зависит» от другой.
На диаграмме важно явно отмечать, какие поля являются внешними ключами, и четко показывать, к какой сущности они ведут. Это не только улучшает читаемость схемы, но и позволяет на раннем этапе выявить потенциальные проблемы в структуре (например, циклические зависимости или забытые связи).
Что важно помнить, прежде чем строить ER-диаграмму:
ER-диаграмма – не просто схема, а карта мира данных. Она должна быть понятной, читабельной и легко проверяемой всеми участниками проекта – от аналитика до архитектора.
PK – это якорь таблицы: уникальный идентификатор, с которого все начинается.
FK – это мост: он соединяет таблицы, указывает, где искать родственную запись.
Кардинальность (1, N, 0..1 и др) – правила игры: сколько записей может быть связано между сущностями и как.
Строим ER-диаграмму
Для построения ER-диаграммы удобно использовать draw.io. Теперь, когда структура визуализирована, разберем ее текстом, что именно означает каждая сущность, ключ и связь в нашей ER-диаграмме.
Покупатель (customer)
Один покупатель может оформить несколько заказов.
Связь 1:N с таблицей order.
Поле customer_id – первичный ключ в таблице customer, используется как внешний ключ в таблице order.
Заказ (order) не просто существует сам по себе – он расщепляется на строки заказа (order_line), каждая из которых указывает, какой джем и в каком количестве заказан.
Заказ (order)
Каждый заказ относится к одному покупателю (customer_id → customer) и может включать несколько строк заказа.
Связь 1:N с таблицей order_line.
Также заказ связан с:
– одним адресом доставки (address_id → address)
– одним статусом (status_id → status)
– одним способом оплаты (payment_method_id → payment_method)
Строка заказа (order_line)
Каждая строка заказа привязана:
– к одному заказу (order_id → order)
– к одному джему (jam_id → jam)
Таким образом, таблица order_line реализует связь многие ко многим (N:M) между таблицами order и jam.
Джем (jam)
Один джем может встречаться в нескольких строках заказа.
Связь 1:N с таблицей order_line.
Адрес (address)
Один адрес может использоваться в нескольких заказах.
Связь 1:N с таблицей order.
Статус (status) и способ оплаты (payment_method)
Каждый заказ содержит только один статус и один способ оплаты.
Это типичные связи 1:N: один и тот же статус или способ оплаты может использоваться в разных заказах, но в каждом заказе указывается только одно значение каждого из этих параметров.
Совет героя
Выбирай удобные инструменты (например, draw.io, Lucidchart, QuickDBD), обозначай ключи (PK, FK), указывай кардинальность (1, N, 0..1), соблюдай чистую визуальную структуру и своевременно обновляй схему при изменениях.
ER-диаграмма – это инструмент, который помогает увидеть всю структуру одним взглядом, еще до того как начнется техническая реализация. Она делает архитектуру прозрачной, обеспечивает общее понимание между аналитиками, разработчиками, архитекторами и заказчиком.
Физическая модель: от простого к сложному
Наш герой многое узнал. Он уже умеет фиксировать данные, различать сущности и чувствовать связи между ними. Теперь настал момент взглянуть на систему «как она есть». Это как раз и есть физическая модель: конкретное техническое описание того, как будет реализована база данных в реальной СУБД (системе управления базами данных).
Что такое физическая модель
Физическая модель – это финальный уровень описания данных, когда от логики и смыслов мы переходим к конкретным параметрам: как именно будут созданы таблицы, какие поля в них будут, какие типы данных, ключи, ограничения. Иными словами, логическая модель говорит «что», а физическая – «как». Мы не будем сильно углубляться в физическую модель так как тема достаточно обширная, но рассмотрим ее базово.
Ключевые аспекты физической модели
Важно: индексы по первичным ключам создаются автоматически. Внешние ключи также могут индексироваться. Это зависит от СУБД. Дополнительные индексы стоит задавать вручную для часто используемых полей. Например, если в таблице customer часто производится поиск по полю email, можно создать индекс вручную:
Это ускорит фильтрацию и поиск без необходимости полного перебора всех записей. Ниже представлена упрощенная таблица физической модели.
Остальные таблицы (order_line, address, status, payment_method) оформляются аналогично.
Пример физической реализации: таблица jam. Разберем, что здесь происходит:
jam_id– целое число, которое увеличивается автоматически (AUTO_INCREMENT).name– обязательное строковое поле до 50 символов.taste– строка, можно оставить пустой (NULL).description– текстовое поле без ограничений по длине (TEXT, а не VARCHAR).
price– десятичное число с двумя знаками после запятой (DECIMAL(8,2)). Для хранения итоговых сумм, например total_sum в заказе, обычно используют DECIMAL(10,2) — он позволяет записывать значения до 99 999 999.99.
Путь аналитика: как читать и проверять физическую модель
Для системного аналитика важно не просто передать структуру, но и:
- Убедиться, что учтены все требования – ключи, связи, ограничения.
- Проверить, что типы данных соответствуют смыслу (например, дата – это
DATE, а неVARCHAR). - Проследить, чтобы структура таблиц обеспечивала быстрый и удобный доступ к данным.
- Согласовать наименования и формат полей с разработчиками и архитекторами.
Теперь перенесем структуру из ER-диаграммы в физическую модель.
Примечание:
В рамках прошлой статьи мы рассмотрели три базовые нормальные формы – 1НФ, 2НФ и 3НФ. Они помогают выстроить непротиворечивую, логично организованную структуру данных. Помимо них существуют и другие уровни нормализации – 4НФ, 5НФ, DK/NF (доменно-ключевая нормальная форма) и др., цель которых устранение избыточности и сложных зависимостей между атрибутами.
Также важно помнить, что первичный ключ (PK) играет ключевую роль в обеспечении логической и физической целостности данных. Хотя SQL формально допускает создание таблицы без PK, на практике в большинстве проектов его отсутствие усложняет сопровождение, мешает однозначно идентифицировать строки и выстраивать корректные связи между таблицами. Поэтому наличие PK – не обязательное требование языка, но разумная и устойчивая архитектурная практика, особенно в системах с развитыми связями и интеграциями.
В этот момент наш герой открывает глаза – буквально. Он уже не только слышит, улавливает связи или чует риски. Теперь он ясно видит структуру: как из первоначального хаоса требований и фрагментов рождается упорядоченная архитектура, в которой у каждой сущности свое место, у каждой связи обоснованная роль, а вся система надежная, масштабируемая и прозрачная.
Каждая таблица, каждая колонка, каждая зависимость – это не просто технические детали. Это фундамент, который определяет, насколько легко будет системе расти, обновляться, интегрироваться с другими сервисами и справляться с новыми задачами бизнеса.
Совет героя
- Всегда строй структуру осознанно. Смотри не только на текущие требования, но и на перспективу: что может измениться, что будет критично при росте, где потенциальные узкие места.
- Архитектура – это инвестиция. Правильная структура базы данных экономит месяцы и годы на сопровождении, доработках, оптимизации, обучении новых сотрудников.
- Ты как аналитик – не просто посредник, а архитектор смысла. От твоих решений зависит не только то, насколько легко будет работать разработчикам, но и репутация всей команды: стабильность, производительность и отказоустойчивость системы – в том числе твоя зона ответственности.
- Документируй, объясняй, проверяй. Чем понятнее и надежнее структура на этапе физической модели, тем меньше хаоса и путаницы будет в будущем.
Хорошо проработанная физическая модель – это уже почти реализованная система, в которой нет места случайностям. Все продумано: от названия поля до логики внешнего ключа.
И если сделать это правильно сейчас, потом не придется чинить последствия, объяснять заказчику странные ограничения или экстренно перестраивать архитектуру.
А теперь бонус – домашнее задание
Раз мы уже умеем читать, строить и проверять концептуальную и физическую модель, пора немного попрактиковаться.
Открой нашу модель и подумай, что в ней можно улучшить:
• Какие поля или сущности стоит добавить, чтобы база стала полезнее?
• Что можно убрать или объединить, чтобы избавиться от избыточности?
Сначала дополни концептуальную модель, а затем физическую.
Постарайся объяснить, зачем ты это делаешь. Так ты начнешь мыслить, как архитектор системы.
(P.S. Если пропустили эволюцию героя: Часть 1 → уши, Часть 2 → лапы, Часть 3 → артефакты, Часть 4 → когти, Часть 5 → Реляционная база данных).
