Workflow моделирования: от требований к схеме
Модель данных не появляется из воздуха и не пишется за один проход. Это результат процесса — последовательности шагов от «бизнес что-то рассказал» до «схема создана и проверена». В прошлом уроке мы разобрали три уровня модели как состояния. Этот урок — про процесс, который проводит модель через эти состояния, и про то, почему процесс итеративный, а не линейный.
Понимание workflow важно практически: оно говорит, с чего начать перед чистым листом и как не утонуть в задаче.
Откуда берётся модель: требования
Любая модель начинается с требований — описания того, что система должна делать с данными. Требования приходят от бизнеса, и собирают их разговором, чтением документов, изучением существующих систем.
Требования бывают двух видов, и оба нужны:
- Что система хранит — про какие сущности данные: клиенты, заказы, товары. Это даёт сущности и связи.
- Что система делает с данными — какие вопросы будут задавать, какие операции выполнять: «показать заказы клиента за месяц», «посчитать выручку по категориям». Это даёт паттерны доступа.
Второй вид новички часто упускают, а он критичен. Модель проектируется не только под то, ЧТО хранить, но и под то, КАК это будут спрашивать. Одни и те же сущности при разных паттернах доступа дадут разные модели — особенно ярко это во второй половине курса, где OLTP и OLAP моделируют по-разному именно из-за разных паттернов.
Самые дорогие ошибки моделирования закладываются здесь, на этапе требований. Если неверно понял предметную область — пропустил сущность, неправильно понял связь — дальше безупречная техника просто аккуратно построит неправильную модель. Поэтому требования не «формальность перед настоящей работой» — это её фундамент.
Шаги workflow
Классический процесс моделирования — это движение от требований через три уровня модели к проверке. Разложим по шагам.
Шаг 1. Сбор требований. Разговоры с бизнесом, изучение документов. На выходе — понимание предметной области: какие сущности, связи, какие вопросы к данным.
Шаг 2. Conceptual-модель. Из требований выделяем главные сущности и связи. Эту модель показываем бизнесу и сверяем: верно ли понята предметная область. Дёшево исправить здесь.
Шаг 3. Logical-модель. Conceptual обрастает деталями: атрибуты, первичные и внешние ключи, нормализация. Структура становится строгой, но ещё не привязана к СУБД. Здесь основная инженерная работа.
Шаг 4. Physical-модель. Logical переводится в конкретную СУБД: типы данных, индексы под ожидаемые запросы, физические ограничения. Результат — DDL.
Шаг 5. Реализация и проверка. DDL исполняется, в схему грузятся тестовые данные, прогоняются запросы из требований. Здесь выясняется, действительно ли модель отвечает на вопросы, ради которых создавалась.
Шаги 2-4 — это и есть три уровня модели из прошлого урока, поставленные в процесс. Шаг 1 их питает, шаг 5 их проверяет.
Почему процесс итеративный
Описанные пять шагов выглядят как прямая линия. На практике это не линия, а цикл. Моделирование итеративно: вы проходите шаги, обнаруживаете проблему, возвращаетесь назад, исправляете, идёте дальше снова.
Почему возвраты неизбежны:
- Проверка вскрывает упущенные требования. На шаге 5 пытаетесь ответить на вопрос из требований и понимаете, что нужной связи в модели нет. Возврат к шагу 2 или 3.
- Logical-моделирование вскрывает неясность в conceptual. Нормализуя структуру, обнаруживаете, что не понимаете связь между двумя сущностями. Возврат к бизнесу за уточнением.
- Бизнес уточняет требования по ходу. Увидев conceptual-модель, заказчик говорит: «а, забыл сказать — у клиента может быть несколько адресов». Требования изменились — модель меняется.
- Реальные данные не лезут в модель. Загрузили тестовые данные и увидели случай, который схема не предусмотрела.
Итеративность — это не признак того, что вы плохой проектировщик. Наоборот: ожидание, что модель будет готова с первого прохода, — вот признак неопытности. Опытный проектировщик закладывает итерации в план и проходит ранние циклы быстро и дёшево, пока модель ещё на бумаге.
Делайте ранние итерации максимально дешёвыми. Первые проходы — на бумаге или в редакторе диаграмм, без кода. Чем раньше в цикле найдена ошибка, тем дешевле правка — это прямое следствие «цены изменения схемы» из первого урока модуля. Не торопитесь писать DDL: сначала прогоните пару дешёвых итераций на уровне conceptual/logical.
Хороший приём: проверять модель запросами
Самый надёжный способ проверить модель — ещё до написания кода прогнать по ней требования-вопросы мысленно или на наброске. Для каждого вопроса из требований («показать выручку по месяцам») спросите: легко ли на него ответить в этой модели? Какие таблицы соединять? Сколько соединений?
Если ответ на частый, важный вопрос требует пяти соединений и подзапроса — это сигнал, что модель стоит пересмотреть. Если ответа нет вообще, потому что нужных данных в модели не предусмотрено, — вы только что нашли упущенное требование, и нашли дёшево.
Этот приём — «вести моделирование от запросов» — особенно важен для аналитических моделей и доходит до предела в NoSQL, где схему проектируют строго от запросов (query-first). Но и в обычном реляционном моделировании привычка проверять модель вопросами экономит много итераций.
Где workflow ломается у новичков
Полезно знать, на каких шагах процесс чаще всего идёт не так у начинающих — это самые частые сбои.
Слишком быстрый переход к коду. Соблазн пропустить conceptual- и logical-уровни и сразу писать CREATE TABLE велик: кажется, что «настоящая работа» — это код. Но прыжок к коду пропускает дешёвые итерации на бумаге и переносит исправление ошибок на дорогой этап. Дисциплина «сначала диаграмма» экономит недели.
Сбор требований как формальность. Новичок задаёт бизнесу пару вопросов и спешит проектировать. В итоге половина паттернов доступа выясняется уже на проверке, и модель переделывается. Требования стоит собирать дотошно: лучше задать на десять вопросов больше сейчас, чем переделывать схему потом.
Проектирование без проверки запросами. Модель «выглядит красиво» — значит готова? Нет. Пока вы не прогнали по модели реальные вопросы-требования, вы не знаете, работает ли она. Проверка запросами — обязательный шаг, а не опциональный.
Страх итераций. Новичок воспринимает возврат назад как провал и пытается «угадать» идеальную модель с первого раза. Это приводит к долгому параличу на этапе проектирования. Правильнее — быстро сделать черновую версию и улучшать её итерациями.
Если ловите себя на мысли «модель ещё не идеальна, ещё рано её проверять» — это и есть страх итераций. Несовершенную модель надо проверять как можно раньше: именно проверка покажет, что в ней несовершенно. Идеальная модель в голове, которую боятся вынести на проверку, бесполезна.
Документирование как часть процесса
Workflow не заканчивается готовой схемой. Модель надо задокументировать: что означает каждая сущность и атрибут, какие бизнес-правила заложены, почему приняты те или иные решения. Без документации модель через полгода становится загадкой даже для своего автора, а для нового члена команды — тем более.
Документация — не отдельный этап «когда будет время», а сопровождающая работа на всех шагах. ER-диаграмма — уже часть документации. Описания атрибутов, комментарии к таблицам в DDL, зафиксированные бизнес-правила — всё это делает модель понятной и поддерживаемой. Современные инструменты (dbt docs и подобные) умеют генерировать документацию и диаграммы связей прямо из кода.
Попробуй сам
Возьмите небольшое ТЗ — например: «Сервис бронирования переговорных комнат. Сотрудники бронируют комнаты на время. Нужно: показать брони сотрудника, показать свободные комнаты на заданный час, посчитать загрузку каждой комнаты за неделю». Пройдите workflow на бумаге: выпишите требования двух видов (что хранит — что делает), постройте conceptual-модель, наметьте logical с ключами. Затем сделайте главное — для каждого из трёх вопросов-требований проверьте, легко ли на него ответить в вашей модели, какие таблицы соединять. Если какой-то вопрос даётся тяжело — вернитесь и доработайте модель. Запишите, что именно изменилось между первой и второй версией: это и есть итерация, прожитая своими руками.