Схема данных словами помогает описать сущности и связи без жаргона. Даем понятный шаблон, проверку через операции и короткий чеклист.
Схема данных словами - это короткое текстовое описание того, какие объекты есть в продукте, как они называются по-русски, какие у них поля и как они связаны друг с другом. Это не диаграмма и не набор таблиц, а понятный рассказ, который можно прочитать за 5 минут и понять одинаково.
Ее стоит писать до разработки по простой причине: почти все дорогие ошибки рождаются не в коде, а в недоговоренностях. Пока вы не договорились, что такое «клиент», чем «заказ» отличается от «заявки» и что значит «оплачен», любые макеты и даже работающий интерфейс будут вести к разным ожиданиям у бизнеса, дизайна и разработки.
Таблицы и диаграммы часто не спасают, потому что прячут смысл. В них видно поля и связи, но не видно правил жизни: что обязательно, что может быть пустым, что происходит при удалении, кто и когда меняет статус, что считается «единственным» (например, «у пользователя может быть только один активный тариф»). Еще одна типичная проблема - одинаковые слова с разным смыслом: «пользователь» как человек, «пользователь» как учетная запись и «пользователь» как плательщик.
Текст хорошо снимает споры про термины, потому что заставляет формулировать: «мы называем это так, и вот критерий». Если в команде появляются разные трактовки, они становятся заметны сразу - прямо на уровне предложений.
Обычно хороший результат укладывается в 1-2 страницы: небольшой словарь терминов, список сущностей с главными полями, связи между сущностями, несколько примеров операций (создать, изменить, оплатить, отменить) и пара неочевидных правил (ограничения, уникальность, что удаляем, что архивируем).
Например, вместо «есть таблицы users и orders» пишут так: «Пользователь - это учетная запись. Заказ - это намерение купить услугу. Один пользователь может создать много заказов, но оплатить заказ может другой плательщик. После оплаты заказ нельзя удалять, только отменять». Такие фразы сразу показывают, что нужно уточнить еще до кода и прототипов.
Чтобы описать схему данных словами, удобно договориться о трех терминах: сущность, поле и связь. Это небольшой «словарь проекта»: если вы одинаково понимаете эти слова, дальше будет меньше споров и переделок.
Сущность - это предмет учета: то, что вы хотите хранить и с чем будете работать в операциях. Обычно это существительное в единственном числе: «Клиент», «Заказ», «Оплата», «Сотрудник», «Услуга».
У сущности бывают записи (экземпляры). «Клиент» как сущность - это тип объекта, а «Иван Петров, телефон..., дата рождения...» - конкретная запись. Если сущность существует, значит почти всегда нужен список записей: список клиентов, список заказов, список оплат. И сразу полезно уточнить, как вы находите запись в этом списке (по номеру, телефону, email, коду).
Поле - это свойство записи. У «Клиента» это может быть имя, телефон, дата регистрации. У «Заказа» - сумма, дата, комментарий.
Чтобы поле не оставалось «на глаз», в тексте фиксируют минимум: тип (текст, число, дата, да/нет, список значений), обязательность (может быть пустым или нет), пример значения и особые правила (уникальность, формат, ограничения).
Например: «телефон: строка, обязателен, уникален, пример +7 999 123-45-67». Такая одна строка часто спасает от ошибок и в интерфейсе, и в базе.
Связь - это правило между двумя сущностями. Она отвечает на вопрос: как одна запись относится к другой.
Простой пример: «Заказ принадлежит Клиенту». Это значит, что у каждого заказа есть ровно один клиент, а у клиента может быть много заказов. В словесном виде полезно всегда говорить обе стороны: «один заказ - один клиент; один клиент - много заказов».
Связи важны тем, что влияют на операции. Например, если удалить клиента, что делать с его заказами: запретить удаление, удалить вместе с заказами или оставить заказы, но без клиента? Эти решения лучше проговорить словами заранее, чем обнаружить проблему на реальном сценарии.
Сущность - это «тип вещи», с которой работает ваш продукт: клиент, запись, заказ, платеж. Чтобы описание не превратилось в абстракцию, пишите так, будто объясняете это человеку из поддержки или бухгалтерии.
Начните с названия. Укажите рабочее имя (как в документах) и «человеческое» (как говорят пользователи). Иногда это разные слова: «Клиент» в системе и «Посетитель» в диалогах, «Заявка» и «Обращение». Если есть синонимы, перечислите 2-3 и выберите одно основное.
Дальше дайте короткое определение в 1-2 предложениях: что это такое и зачем это хранится. Удобная формула: «Сущность X хранит ... чтобы ...». Например: «Запись хранит время визита и выбранную услугу, чтобы администратор мог управлять расписанием и подтверждениями».
После этого зафиксируйте ключевые поля: только то, без чего запись не имеет смысла. Держите себя в рамке 4-7 полей, остальное вынесите в «дополнительно».
Шаблон, который можно копировать:
Правила качества лучше писать как проверяемые условия. Не «корректный телефон», а «телефон в формате +7XXXXXXXXXX, хранится без пробелов». Не «уникальный email», а «email уникален среди активных клиентов; регистр не учитывается». Сюда же добавляйте допустимые значения: «тип клиента: физлицо | юрлицо», «язык: ru | en». Если есть поля, которые часто путают, зафиксируйте смысл: чем «комментарий» отличается от «примечания для внутреннего пользования».
В конце дайте пример одной записи, максимально жизненный. Это быстро выявляет дыры: вы сразу увидите, чего не хватает (например, часовой пояс, валюта, источник заявки).
Пример:
Сущность: Клиент (пользователи говорят: «посетитель», «человек»)
Назначение: хранит контактные данные и согласия клиента, чтобы можно было записывать на услуги и отправлять уведомления.
Обязательные поля:
Правила качества данных:
Пример записи: {id: 1042, имя: "Ирина", телефон: "+79161234567", дата_создания: "2026-01-12"}
В текстовой схеме больше всего путаницы обычно не на уровне сущностей, а на уровне полей: что хранить как есть, что выносить в справочник, какие статусы бывают и что считается автоматически.
Справочник нужен там, где значение должно быть одинаковым у всех и повторяться много раз. Это снижает ошибки и делает отчеты понятнее. Свободный текст оставляйте там, где заранее нельзя перечислить варианты или важна формулировка пользователя.
Ориентир простой: город, валюта, тип услуги, роль пользователя, причина отмены (если причин мало и они фиксированы) обычно лучше делать справочником. Комментарии, адрес в свободной форме, пожелания клиента и описание проблемы - текстом. Частый компромисс - «справочник + другое (текст)».
Сразу запишите: кто управляет справочником (админ, менеджер, система), можно ли добавлять новые значения и что делать со старыми (архивировать или удалять).
Статусы описывают жизненный цикл объекта. Для каждого статуса полезно зафиксировать смысл, кто может его поставить и что разрешено делать дальше. Одних слов «новый, в работе, завершен» почти всегда недостаточно.
Удобный формат:
Мини-сценарий: «Запись на услугу» может иметь статусы «создана», «подтверждена», «отменена», «проведена». Переход «проведена -> отменена» чаще всего запрещен, а «подтверждена -> отменена» разрешен, но требует причину отмены из справочника.
История нужна, если важно отвечать на вопрос «кто и когда поменял». Обычно это цена, статус, исполнитель, дата визита. Если поле техническое и не влияет на решения, часто хватает текущего значения.
Сразу уточните: какие поля логировать, как долго хранить историю и нужен ли комментарий к изменению (например, при отмене).
Если значение считается, запишите формулу словами и источник данных. Например: «итого к оплате = сумма услуг - скидка + сервисный сбор». Отдельно решите, храните ли вы итог в базе или пересчитываете каждый раз. Хранить удобно для скорости и отчетов, но тогда нужно правило, когда и кем итог пересчитывается.
Связь в схеме данных словами отвечает на вопрос: как два объекта относятся друг к другу в жизни, и что будет, если один из них исчезнет. Хорошее описание связи обычно помещается в 3-5 коротких фраз и снимает споры еще до начала разработки.
Начните со смысла, а не с технических терминов. Дальше уточните кратность, обязательность и поведение при удалении.
Про кратность пишите человеческими словами, а в скобках можно добавить привычный ярлык: (1:1), (1:N), (N:M). Например: «У одной записи может быть много платежей (1:N)».
Обязательность удобнее формулировать через действие пользователя: «Можно ли создать X, если Y еще нет». Это сразу показывает, где нужны черновики, статусы или отложенное заполнение.
Удаление описывайте не как кнопку, а как правило безопасности. Чаще всего подходит один из трех вариантов: запретить удаление, если есть зависимые записи; отвязать связь, но не трогать данные; архивировать вместо физического удаления.
«Запись на услугу относится к одному клиенту, а у клиента может быть много записей (1:N). Запись нельзя создать без клиента. Клиента удалять нельзя, пока есть записи; вместо этого ставим статус "архив"».
«Платеж относится к одной записи, а у записи может быть несколько платежей (1:N). Платеж можно создать только для существующей записи. Если запись отменена, платежи не удаляем, а помечаем как "возврат" или "неактуален" по бизнес-правилу».
«Услуга и мастер связаны многие ко многим (N:M): мастер может делать несколько услуг, и услугу могут делать несколько мастеров. Связь хранит доп. поля: цена для этого мастера и длительность. При удалении мастера связь удаляем, но услуги остаются».
Текстовая модель хороша до тех пор, пока вы не попробуете сделать с ней реальную работу. Самая простая проверка: пройтись по ключевым операциям пользователей и посмотреть, хватает ли сущностей, полей и правил, чтобы выполнять эти операции без догадок.
Начните с 8-15 действий, которые люди делают чаще всего: создать, изменить, найти, отменить, оплатить, восстановить. Формулируйте как пользователь: «Записаться на услугу», «Найти запись по телефону», «Вернуть оплату».
Для каждой операции пройдите один и тот же маршрут:
Возьмем операцию «Создать запись на услугу». Участвуют сущности: Клиент, Услуга, Запись, иногда Платеж. Теперь задайте пару реальных кейсов.
Кейс А: клиент новый. Сначала ищем Клиента по телефону (читаем phone). Если не нашли - создаем Клиента (пишем имя, phone). Потом создаем Запись (пишем client_id, service_id, время, статус).
Кейс Б: клиент уже есть, но пытается записаться на то же время. Тут сразу видно, нужно ли правило уникальности: например, «в одном слоте у мастера только одна запись». Если мастера как сущности еще нет, проверка будет нечестной: значит модель неполная.
Полезный тест - придумать, как операция ломается: «запись уже отменена», «нет прав менять чужую запись», «услуга архивирована», «оплата уже проведена». Если вы не можете указать, где хранится статус и кто его меняет, схему нужно дописать.
Возьмем понятный сценарий: клиент выбирает услугу, записывается на время, оплачивает, иногда переносит запись или отменяет, а иногда просит возврат. Такая «схема данных словами» быстро показывает, где в модели будут пробелы.
В минимальном варианте достаточно четырех сущностей: Клиент (кто получает услугу), Услуга (что продаем), Запись (конкретный визит), Платеж (факт оплаты).
Уже здесь важно проговорить обязательность. Клиента и услугу можно создать заранее. Запись можно создать без платежа (если разрешаете бронь) или только после оплаты (если у вас предоплата обязательна). Платеж почти всегда создается только для существующей записи, иначе будет непонятно, за что он.
Пройдитесь по действиям, которые реально будут в системе: создать запись (что фиксируем сразу и какой начальный статус), перенести время (меняем только время или еще длительность, специалиста, цену), отменить запись (что происходит с платежом), вернуть платеж (частичный или полный, отдельной операцией или отдельной сущностью).
После такого прогона всплывают вопросы, которые лучше решить до разработки. Например: цена услуги может измениться - значит в записи нужна «зафиксированная цена». Нужна ли запись без клиента (быстрая бронь) или клиент обязателен. Может ли быть несколько платежей на одну запись (доплата, предоплата + остаток). Что считать источником правды: статус записи зависит от платежа или живет отдельно.
Если вы можете ответить на эти вопросы простыми фразами, текстовое описание уже похоже на рабочую модель, а не на набор терминов.
Самая частая проблема - когда текст вроде бы понятный, но из него нельзя однозначно собрать таблицы, связи и правила. В итоге каждый читает по-своему, а ошибки всплывают уже на тестах.
Одна из коварных ловушек - смешивание разных смыслов в одном поле. Например, поле status одновременно пытается сказать «оплачено/не оплачено» и «почему не оплачено» (ошибка банка, клиент передумал, истек срок). Потом вы не можете строить отчеты: статус один, причин много. Лучше разделять: статус (короткий набор значений) отдельно, причина (справочник или текст с правилами) отдельно.
Вторая боль - нет определения уникальности. Если не прописать, что именно делает сущность «единственной», дубликаты появятся неизбежно. Пример: «клиент» без правила уникальности. Это один клиент по телефону? По email? По паре «ФИО + дата рождения»? Пока это не сказано, два менеджера создадут двух «одинаковых» клиентов, и дальше связи расползутся.
Еще одна ловушка - слишком много свободного текста там, где нужен справочник и правила. Город, тип услуги, канал записи, причина отмены: если оставить это текстом, вы получите десятки вариантов написания и невозможность нормально фильтровать.
Часто связи описаны, но не сказано, что происходит при удалении. Если удалить услугу, что будет с записями клиентов: запрещаем удалять, архивируем или каскадно удаляем? То же самое с клиентом, платежом, филиалом.
И последнее: проверяют только «как хранить», но не «как пользоваться». Если вы не перечислили типовые операции поиска и фильтры, можно случайно выбрать структуру, в которой невозможно быстро найти «все записи на завтра по мастеру» или «все неоплаченные за месяц по услуге».
Перед стартом разработки полезно на 20 минут остановиться и проверить текстовое описание схемы данных. Это дешевле, чем переделывать базу и логику после первых ошибок в проде.
Пройдитесь по схеме как по документу, который другой человек сможет использовать без ваших пояснений.
Выберите несколько типичных действий и проверьте, что по вашему тексту можно однозначно ответить «что будет в данных».
Если хотя бы в одном тесте появляется ответ «ну это зависит» или «мы потом решим», допишите правила сейчас. Обычно именно там и прячутся баги и переделки.
Когда текстовая модель уже выглядит цельно, не спешите сразу «рисовать таблицы». Сначала проверьте, что все понимают одно и то же. Самый быстрый способ - собрать короткий словарь терминов: одно слово - одно значение. Например, «клиент» и «пользователь» это одно и то же или разные роли? «Заказ» и «заявка» отличаются статусами или это разные сущности?
Дальше договоритесь о правилах именования. Заранее выберите стиль для полей и статусов и держите его везде одинаковым: как вы называете даты (created_at или датаСоздания), как пишете статусы (DRAFT/PAID или «Черновик/Оплачен»), какие поля обязательны. Это мелочь, но она сильно снижает путаницу, когда текст превращается в реальные объекты.
Чтобы изменения не превращались в хаос, ведите версии. Достаточно простого журнала: что поменялось, почему, кто согласовал. Например: «Добавили статус "Возврат" для платежа, потому что нужен отдельный сценарий отмены».
Теперь превратите описание в план работ, ориентируясь на пользовательские задачи: сначала минимальная версия сущностей и полей, затем статусы и переходы, потом связи и правила удаления, после этого 3-5 ключевых операций (создать, изменить, отменить, оплатить) и тестовые данные.
Если вы собираете прототип через TakProsto (takprosto.ai), удобно начать с Planning mode: там проще держать в одном месте сущности, поля, связи и сразу прогонять операции на тестовых примерах. А перед крупными правками можно сохранять снимки, чтобы сравнить изменения и при необходимости откатиться.
Это короткий текст, который объясняет, какие объекты есть в продукте, как вы их называете, какие у них основные поля и как они связаны. Он нужен, чтобы команда одинаково понимала смысл терминов и правил до того, как появятся макеты, таблицы и код.
Потому что большинство дорогих ошибок — это не баги в коде, а разные трактовки «что мы строим». Текст быстро выявляет, где вы по-разному понимаете «клиента», «заказ», «оплачено», и позволяет договориться до того, как изменения станут дорогими.
Обычно хватает 1–2 страниц, если держать фокус на главном. Старайтесь уложиться в словарь терминов, список сущностей с ключевыми полями, связи, 8–15 основных операций и несколько критичных правил вроде уникальности, удаления и статусов.
Начните с названия и определения в 1–2 предложениях по формуле «Сущность X хранит … чтобы …». Затем перечислите 4–7 ключевых полей и сразу зафиксируйте для каждого тип, обязательность и пример значения, чтобы не осталось «на глаз».
Минимум: тип значения, обязательность и пример, плюс правила качества данных. Если поле должно быть уникальным или иметь формат, пишите это проверяемым условием, чтобы потом одинаково трактовали и интерфейс, и базу.
Если варианты значений должны быть одинаковыми у всех и часто повторяются, делайте справочник. Если важна формулировка пользователя или вариантов заранее не перечислить, оставляйте свободный текст, но заранее решите, как вы будете его использовать в поиске и отчетах.
Описывайте не только список статусов, а смысл каждого статуса и правила переходов: кто меняет, из какого статуса в какой можно, и что при этом происходит. Так вы избегаете ситуаций, где «отменено» вдруг означает и «не оплачено», и «вернули деньги».
Скажете смысл связи, кратность с обеих сторон, можно ли создать запись без пары и что будет при удалении. Это сразу отвечает на практические вопросы вроде «можно ли создать запись без клиента» и «что делать с заказами, если клиент удален».
Пройдитесь по ключевым операциям и прогоните их на конкретных кейсах с реальными значениями. Если где-то появляется вопрос «а откуда это берется», «кто меняет статус» или «что считается дубликатом», значит в модели не хватает поля, статуса, ограничения или сущности.
В Planning mode удобно собрать сущности, поля, связи и сразу пройтись по операциям как по чек-листу, чтобы быстро найти пробелы. Перед крупными изменениями полезно сохранять снимки и при необходимости откатываться, а когда модель согласована — экспортировать исходники и двигаться дальше без потери договоренностей.
