Модель данных для аналитика: сущности, связи и словарь данных

В постановке — «клиент», в интерфейсе — «покупатель», в базе — user и account, у бухгалтерии — «контрагент». Все уверены, что говорят об одном. Разница обнаруживается, когда у одного клиента оказывается две учётные записи и отчёт считает его дважды.

Модель данных принято считать делом разработчиков: таблицы, ключи, индексы. Но схема базы отвечает на вопрос «как хранится», а аналитику нужен другой — «что вообще существует в предметной области и по каким правилам». Если этот вопрос не задан, на него отвечает схема, и отвечает так, как удобно хранить, а не так, как устроен бизнес.

Цена ответа появляется позже: правило, зашитое в структуру, меняется не правкой постановки, а миграцией.

Логическая модель и схема базы

Разделение старое и полезное. Логическая модель описывает сущности, их смысл, связи и правила — без привязки к технологии. Физическая схема решает, как это разложить по таблицам, какие поля индексировать, что денормализовать ради скорости.

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

Три вопроса к каждой сущности

Что это — одним предложением. Не «заказ — это заказ», а «заказ — обязательство продать перечисленные товары по зафиксированной цене одному покупателю». Определение, которое нельзя сформулировать, означает, что сущностей на самом деле две.
Чем одна отличается от другой. Что делает две записи одним и тем же: номер, сочетание полей, внешний идентификатор? От ответа зависит, что считать дублем и как сливать данные из двух источников.
Как она живёт. Кто её создаёт, какие статусы она проходит, может ли вернуться назад, удаляется ли вообще — или только помечается закрытой.

Удаление — отдельное требование. «Удалить клиента» может значить три разных вещи: скрыть из интерфейса, обезличить данные или стереть физически вместе с историей заказов. Для отчётов, договоров и закона это разные решения, и выбирать их должен не разработчик.

Связи — там, где прячутся требования

Каждая связь между сущностями — это бизнес-правило, записанное в форме «один ко многим». Такие правила меняются, и меняются они дороже всего, потому что на них опирается всё остальное.

Связь в модели	Вопрос, который стоит задать	Что сломается, если ответ «да»
Заказ принадлежит одному клиенту	Бывают ли заказы без клиента — гостевые?	Отчёты по клиентам, удаление клиента, повторная покупка
У заказа один адрес доставки	Можно ли отправить часть заказа в другое место?	Расчёт доставки, статусы, возвраты по частям
У товара одна цена	Нужна ли цена на момент заказа, а не текущая?	Повторный расчёт старых заказов по новой цене
У пользователя одна роль	Бывает ли человек одновременно менеджером и проверяющим?	Права доступа, разделение обязанностей

Хорошая привычка — формулировать связь словами в обе стороны: «у заказа ровно один клиент; у клиента ноль или больше заказов». Слово «ровно» почти всегда вызывает возражение, и это возражение — найденное требование.

Словарь данных

Модель показывает сущности и связи. Словарь данных — что значит каждое поле. Именно в нём живут вопросы, которые иначе всплывают на приёмке: включает ли сумма доставку, в какой валюте, как округляется.

Заказ.сумма
  смысл          итог к оплате покупателем, с доставкой, после скидок
  формат         число, 2 знака после запятой, валюта заказа
  обязательно    да, с момента подтверждения заказа
  источник       расчёт системы; вручную не меняется
  правила        округление по BR-07; при частичном возврате не меняется,
                 возврат хранится отдельно
  пример         1 249,90

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

Где кончается работа аналитика

Типы колонок, индексы и нормализация — не предмет постановки. Но есть свойства данных, которые выглядят техническими, а на деле являются требованиями, и добавить их задним числом нельзя:

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

Признак, что модели нет: на вопрос «что такое активный клиент» отдел продаж, бухгалтерия и отчёт отвечают по-разному — и все правы.

Проверка за двадцать минут

Возьмите три сущности из главного сценария продукта. Попросите разработчика и заказчика по отдельности дать каждой определение одним предложением. Сравните. Каждое расхождение — требование, которое пока живёт в двух головах.

Что дальше

Модель говорит, что хранится и как связано. Она молчит о том, сколько этого будет, как быстро должно находиться и сколько система может простоять. Это нефункциональные требования — и их чаще всего пишут так, что проверить нельзя.