Сегодня вторник, а значит, мы с бизнес-аналитиком Юлией Чугуновой разбираем архитектуру данных – от бизнес-сущностей до связей в БД (базе данных). Все предыдущие статьи по теме бизнес-анализа можно найти тут. А сейчас – учимся переводить требования в структуру таблиц, разбираем, как избежать «костылей» в базе и почему ошибки в данных дороже багов. И главное – строить реляционные модели, которые не развалятся при масштабировании.
«Представьте библиотеку: пользователь видит красивые залы, а аналитик проектирует каталог. Если структура данных – ваша “система хранения” – продумана, поиск решения занимает минуты. Если нет – книги-требования теряются навсегда.»
После «лап» (фасилитация) и «когтей» (сценарии) наш герой обретает скелет Реляционная база данных: сущности, атрибуты, ключи и связи на реальном проекте каркас, который превращает разрозненные данные в стройную систему. В этой части:
- Концептуальная модель – как выделить сущности из требований (на примере джемов),
- Нормализация – 3 правила против дублей и хаоса (1NF, 2NF, 3NF простым языком),
- Ключи и связи – почему «один ко многим» помогает избежать адских правок.
Готовы проектировать базы, которые не кричат «SOS» при первой же нагрузке? Поехали!
Сущности и связи. Архитектура данных
«Суть проектирования базы данных в понимании реальных сущностей и связей между ними,» – по мотивам идей Питера Чена, основателя ER-модели (1976)
Наш герой уже научился слышать и ловко фиксировать смыслы своими длинными лапами, а его гибкий позвоночник помогает собирать разрозненные данные в единое целое. Он окреп, обрел внутреннюю опору, но все еще воспринимает мир наощупь. В этой главе ему предстоит главный шаг: впервые представить, как из фрагментов информации рождается стройная система, где у каждого элемента свое место и все работает слаженно.
Почему важно говорить про структуру
Метафора: великая библиотека
- Пользователь – как читатель: берет книгу и наслаждается.
- Аналитик – как библиотекарь: думает, где все лежит, легко ли добавить новые полки.
- Интерфейс – красивые залы и понятные указатели.
- Структура данных – это каталог и система хранения. Если все четко, поиск м дело пары минут. Если каталога нет, книги теряются.
В современной ИТ-системе «каталог» – это правильно построенная база данных.
Базы данных: что это и как с ними работать
База данных – электронное хранилище, где информация удобно упорядочена.
В чем отличие:
В реляционных базах структура: строки – записи, столбцы – свойства.
В нереляционных структура свободная.Зачем разбираться в типах баз данных?
Аналитик должен понимать, где и как хранятся ключевые данные, чтобы быстро их находить, изменять и уверенно обсуждать архитектуру с командой. Особенно это важно при проектировании или развитии сложных систем, где ошибка в структуре может дорого обойтись.
В этой главе мы будем опираться на пример реляционной базы данных. Такой выбор не случаен: именно реляционная структура – привычные нам таблицы, строки и связи – наиболее наглядна и часто встречается в бизнес-проектах.
Зачем такой подход?
Это позволит шаг за шагом разобрать, как из бизнес-смысла и реальных потребностей рождается четкая, гибкая и надежная архитектура: от общего представления – до конкретных таблиц и полей.
Теперь, когда мы собрали требования, поняли, какие объекты будут в системе, и какие связи между ними существуют – пора взглянуть на данные с трех сторон: смысловой, структурной и технической. Это и есть три уровня моделей, с которыми работает аналитик:
Наш герой будет учиться разбирать сложное на простое и видеть, как каждый элемент структуры занимает свое место и поддерживает целостность будущей системы.
Концептуальная модель: что есть в нашей системе
Концептуальная модель представляет собой простую схему, где видно:
- какие объекты будут в системе,
- что важно знать о каждом объекте.
Вспоминая наши собранные требования мы организуем ее в понятный для чтения вид. Пример:
Концептуальная модель помогает увидеть все целиком и убедиться, что ничего не забыто.
Нормализация: как навести порядок в данных
Прежде чем перейти к построению следующего уровня модели, важно разобраться с нормализацией данных. Именно нормализация становится тем принципом, который позволяет привести нашу структуру к порядку, заложить основу для надежной архитектуры.
Нормализация – это процесс приведения базы к таким правилам, чтобы:
- информация хранилась только в одном месте,
- не возникало дублей,
- не было “сломанных” связей,
- структуру можно было безболезненно менять.
Если не нормализовать базу:
- появится избыточность – данные повторяются в разных таблицах,
- легко “потерять” или исказить информацию,
- любые изменения станут сложными.
Три основные нормальные формы (НФ):
Первая нормальная форма (1NF)
Атомарность: в каждой ячейке таблицы должно быть только одно значение. Например, только один телефон – не список телефонов через запятую.
Уникальность строк: каждая строка идентифицируется уникально по первичному ключу (PK).
Почему важно:
Это исключает “мешанину” данных, делает структуру таблицы предсказуемой и удобной для поиска, обновления и анализа.Тренды и фишки из мира IT,
экспертные статьи и всё о тестировании.
Вторая нормальная форма (2NF)
Таблица уже выполнена в первой нормальной форме (1NF), то есть нет списков в ячейках, а строки уникальны.
Важное правило: если ключ в таблице состоит из нескольких полей (составной ключ), то каждое поле с данными (не входящее в ключ) должно зависеть от всех этих полей вместе, а не от части.
Пример. В таблице с деталями заказа ключ – это сочетание номера заказа (order_id) и номера товара (product_id). Количество товара (quantity) зависит от обеих этих частей вместе – и это правильно.
Но если в этой таблице хранить название товара, которое зависит только от product_id, это неправильно – такое название надо хранить отдельно, в таблице с товарами.
Почему это важно:
Чтобы данные не повторялись зря и не путались – информация должна храниться только там, где она полностью зависит от ключа.Третья нормальная форма (3NF)
Таблица уже отвечает требованиям второй нормальной формы (2NF).
В таблице не должно быть зависимостей между столбцами, которые не являются ключами.
Что это значит простыми словами?
Каждое поле в таблице должно напрямую зависеть только от главного идентификатора записи (первичного ключа), а не от других полей.
Пример. В таблице заказов есть поле с номером клиента (customer_id) и поле с городом (city). Но город можно узнать, посмотрев на данные клиента. Значит, город не нужно хранить в заказах — чтобы не дублировать и не создавать ошибки.
Почему это важно:
Если город меняется, достаточно обновить его в одном месте – в таблице клиентов. Если дублировать в заказах, придется менять в каждом заказе, а это неудобно и опасно – легко сделать ошибку.Запомни! Нормализация – это как генеральная уборка: убирает лишнее, не дает путаться, помогает быстро находить нужное. Даже если данных станет в сто раз больше, система останется чистой и управляемой!
Вдруг нашего героя озарило: «Моя задача, чтобы каждая часть системы знала свое место, а ошибки не прятались в глубине. Нормализация – мои внутренние правила, чтобы не запутаться самому и не спутать команду».
Ключи и связи: как элементы объединяются между собой
Понимание нормализации помогает нам структурировать данные так, чтобы избежать избыточности и ошибок. Но чтобы эта структура работала на практике, нужно правильно определить ключи – специальные поля, которые гарантируют уникальность записей и связывают таблицы между собой.
Давайте разберемся, какие виды ключей бывают и зачем они нужны: первичный ключ (Primary Key, PK) – уникальный идентификатор каждой записи в таблице.
- Обязателен и не может быть пустым.
- Значения уникальны — в таблице не может быть двух строк с одинаковым PK.
- Пример простого PK:
customer_idв таблице покупателей, где каждому клиенту назначается уникальный идентификатор.
Внешний ключ (Foreign Key, FK) – поле (или набор полей) в таблице, указывающее на первичный ключ другой таблицы.
- Обеспечивает связь между таблицами.
- Гарантирует целостность данных: нельзя вставить значение FK, которого нет в связанной таблице.
- Пример: в таблице заказов поле
customer_idссылается наcustomer_idв таблице покупателей, показывая, кто сделал заказ.
Составной ключ (Composite Key) – ключ, состоящий из нескольких полей, объединенных для обеспечения уникальности записи.
- Часто используется для описания связей типа «многие ко многим».
- Пример составного PK: (
order_id, jam_id) в таблице строк заказа, где уникальность определяется комбинацией заказа и конкретного джема.
Ключи – это законы базы: они делают структуру живой и защищенной
Как таблицы связаны между собой?
1. Один ко многим (1:N)
- Один элемент из первой таблицы связан с несколькими элементами из второй.
- Пример: Один покупатель делает много заказов. Но каждый заказ принадлежит только одному покупателю.
- В базе в таблице заказов есть поле
customer_id, которое говорит, кто сделал этот заказ.
2. Многие ко многим (N:M)
- Один элемент из первой таблицы связан с несколькими элементами из второй, и наоборот.
- Пример: В одном заказе может быть много разных джемов. И один джем может быть в многих заказах.
- Для этого создается отдельная таблица – например,
order_line. В ней хранится информация: какой джем в каком заказе и в каком количестве. - То есть таблица
order_lineсоединяет заказы и джемы.
3. Один к одному (1:1)
- Редкая ситуация, когда одному элементу из первой таблицы соответствует ровно один элемент из второй.
- Пример: У покупателя есть дополнительный профиль с расширенной информацией (например, адрес доставки, бонусы). Чтобы не загромождать основную таблицу клиентов, эту информацию кладут в отдельную таблицу – и каждый профиль связан только с одним покупателем.
Для чего знать типы связей?
- Чтобы правильно организовать данные и избежать ошибок.
- Чтобы легко находить нужную информацию.
- Чтобы система работала быстро и понятно.
- Чтобы потом можно было без проблем расширять базу.
Теперь, когда мы знаем про нормализацию, ключи и связи, можем перейти к логической модели.
Заключение
Теперь наш герой видит не просто «джемы» и «заказы», он видит систему:
- Сущности стали четкими (никаких «мутных полей»!),
- Связи – предсказуемыми (спасибо внешним ключам),
- Данные – защищенными от хаоса (благодаря нормализации).
Его новый скелет – это способность превращать:
«Хочу хранить отзывы» → в таблицы
reviews,customers,jamsсо связями,
«Нужна статистика» → в запросы без часовых танцев с бубном.
Что дальше? В новых записках бизнес-аналитика (если Юлина банка с клубнично-кокосовым джемом не опустеет 😉):
- Интерфейсы – как перевести ER-диаграммы в кликабельные прототипы,
- Война правок – как согласовать макеты без потерь для сроков и нервов,
- Техники валидации – почему «показать заказчику экран» важнее 50 страниц SRS.
▫️ Практика. Возьмите любой объект (например, «рецепт джема») и опишите его как сущность: какие свойства у него есть? С чем он связан?
(P.S. Если пропустили эволюцию героя: Часть 1 → уши, Часть 2 → лапы, Часть 3 → артефакты, Часть 4 → когти).
