ER-моделирование
Практическая часть собеса: дают предметную область словами и просят набросать модель прямо на встрече, на доске или в блокноте. Смотрят при этом не на красоту схемы, а на вопросы, которые ты задаёшь по ходу - именно они показывают, умеешь ты моделировать или срисовываешь знакомый шаблон.
Стержень: сначала понятия и связи бизнеса, потом атрибуты, и только в самом конце физические решения. Обратный порядок даёт схему, заточенную под конкретный экран, и она разваливается на втором экране.
// Формулировки: «набросай модель для доставки», «это сущность или атрибут?», «зачем аналитику модель, если базу проектирует разработчик?»
Модель - это язык договорённости
Главная ценность модели предметной области лежит не в схеме, а в вопросах, которые она заставляет задать вслух. Что такое договор? Может ли он существовать без клиента? Сколько адресов бывает у точки выдачи? Меняется ли тип клиента со временем?
Каждый из этих вопросов стоит пять минут на схеме и три недели в проде. Физическую схему разработчик действительно спроектирует сам и, скорее всего, лучше тебя. Но ответов про предметную область у него нет и взять их неоткуда - он не разговаривает с бизнесом.
Отсюда практика, которая заметно повышает выход: рисовать модель вместе с бизнесом, а не приносить готовую на согласование. Половина находок случается ровно в тот момент, когда человек видит нарисованную связь и говорит «нет, у нас бывает и по-другому».
// Готовая схема на согласование, наоборот, провоцирует кивок. Люди плохо ищут ошибки в чужом законченном документе и хорошо - в схеме, которая рождается у них на глазах.
Сущность или атрибут
Граница подвижна и определяется задачей, а не природой вещей. «Город» строкой внутри адреса - атрибут. «Город» со своим справочником, кодом региона, часовым поясом и признаком активности - уже полноценная сущность. Один и тот же город в двух системах окажется по разные стороны границы, и обе будут правы.
Рабочее правило, которое решает спор за секунду: если по части значения нужно искать, группировать или строить отчёт, эта часть обязана быть отдельным атрибутом, а часто и отдельной сущностью. Разбирать строку на лету ненадёжно - форматы у разных пользователей разные, опечатки неизбежны, сокращения тоже.
Обратный симптом - сущность без внятного имени и с двумя десятками разнородных полей, обычно называется «Данные» или «Информация». Это признак незавершённого моделирования: в одну таблицу свалили самого клиента, его контакты и историю обращений, потому что не захотели решать, что из этого что.
// Проверка на свалку простая: попробуй сформулировать, что означает одна строка этой таблицы, одним предложением. Не получается - там больше одного понятия, и их надо развести.
Кратность меняется - модель ломается
Классический сюжет. Сотрудник работал в одном отделе, поле «отдел» лежало прямо в его карточке, всё было хорошо. Теперь он может числиться в двух - и простая ссылка перестаёт годиться.
Соблазн добавить второе поле «отдел 2» надо гасить сразу: завтра отделов станет три, а послезавтра появится вопрос, какой из них основной. Это общее правило моделирования - переход от «одного» ко «многим» требует структурного изменения, появления связующей сущности, а не добавления колонки.
И как только связующая сущность появилась, у неё почти сразу обнаруживаются собственные атрибуты: период работы в отделе, доля ставки, признак основного места. Их некуда было положить, пока связь была простой ссылкой.
// Следом почти всегда идёт вопрос про историю: нужно ли знать, где сотрудник числился год назад. Ответ на него меняет модель сильнее, чем сама множественность, потому что требует хранить не текущее состояние, а последовательность периодов.
Как отвечать: «Заказчик говорит клиент, имея в виду то физлицо, то компанию, то контактное лицо»
Пока за одним словом стоят три разных понятия, любое требование про клиента двусмысленно, и спорить о структуре модели рано - мы просто будем обсуждать разные вещи. Сначала развожу смыслы и закрепляю термины в глоссарии: физлицо, организация, контактное лицо организации. Обязательно проверяю на примерах, что все понимают их одинаково: беру три реальных случая из их работы и прошу назвать, кто есть кто. Только после этого решаю, как это ложится в модель - одна сущность с типом, иерархия или три независимые. Выбор зависит от двух вещей: меняется ли тип со временем и насколько сильно различаются атрибуты. Модель следует за языком, а не наоборот.
Кандидат ставит терминологию перед структурой, проверяет её на примерах и называет критерий выбора реализации вместо готового шаблона. Проверка на примерах - деталь, которая отличает практика: без неё глоссарий согласуют, не читая.
На чём валятся
- −− Строят модель под конкретный экран интерфейса, и она разваливается на втором.
- −− Оставляют за одним словом несколько понятий и получают двусмысленные требования.
- −− Добавляют второе поле вместо связующей сущности, когда значений стало два.
- −− Заводят сущность-свалку с разнородными полями и без внятного имени.
- −− Не спрашивают, что делать с уже накопленными данными при изменении структуры.
Проверьте себя
Пять вопросов из банка по этой подтеме. Всего их 12, остальные разбираются в тренажёре.
- В модели появилась сущность «Данные» с двадцатью разнородными полями. Что это означает?A)Модель достигла нужной степени обобщенияB)Нужен более производительный сервер базыC)Смешаны несколько разных понятийD)Требуется добавить индексы по всем полям
показать ответ и разбор
+C)Смешаны несколько разных понятий// разбор: Безымянная сущность-свалка — верный признак, что моделирование остановилось на полпути: в одну таблицу свалили клиента, его контакты и историю обращений. Такая структура не даёт ни осмысленных связей, ни правил целостности, а любые изменения задевают всех потребителей сразу.
- Заказчик говорит «клиент», подразумевая то физлицо, то компанию, то контактное лицо. Что делать?A)Использовать одну сущность с признаком типаB)Развести понятия и закрепить терминыC)Оставить как есть, разберутся по контекстуD)Назвать сущность абстрактно, чтобы охватить всё
показать ответ и разбор
+B)Развести понятия и закрепить термины// разбор: Пока за одним словом стоят три понятия, любое требование про клиента двусмысленно. Сначала разводят смыслы и закрепляют термины в глоссарии, и только потом решают, как это ложится в структуру: одна сущность с типом, иерархия или три независимые. Модель следует за языком, а не наоборот.
- Сотрудник может работать в нескольких отделах одновременно, а раньше был только в одном. Что меняется в модели?A)Достаточно разрешить пустое значение отделаB)Нужен второй атрибут для второго отделаC)Нужна связующая сущность с периодомD)Достаточно добавить индекс по отделу
показать ответ и разбор
+C)Нужна связующая сущность с периодом// разбор: Переход от одного ко многим ломает прежнюю структуру: ссылка на отдел в карточке сотрудника больше не годится. Появляется отдельная сущность связи, где обычно сразу нужны период действия и доля ставки. Добавление второго поля — тупик: завтра отделов станет три.
- Зачем аналитику модель предметной области, если разработчик всё равно спроектирует базу сам?A)Чтобы контролировать работу разработчикаB)Чтобы ускорить написание миграцийC)Чтобы соблюсти состав проектных документовD)Чтобы согласовать понятия с бизнесом до кода
показать ответ и разбор
+D)Чтобы согласовать понятия с бизнесом до кода// разбор: Модель предметной области — это в первую очередь язык, на котором договариваются с бизнесом: что такое договор, может ли он быть без клиента, сколько адресов бывает у точки. Эти вопросы дешевле задать на схеме, чем обнаружить в проде. Физическую схему разработчик действительно спроектирует сам.
- Какой вопрос к модели данных чаще всего забывают задать бизнесу?A)Сколько записей ожидается в годB)Как называть поля в интерфейсеC)Что делать со старыми даннымиD)Какой цвет использовать для статусов
показать ответ и разбор
+C)Что делать со старыми данными// разбор: Модель обычно проектируют для нового состояния мира и забывают про накопленное. Появился обязательный атрибут — чем заполнить его у миллиона старых записей? Разделили сущность — как разложить прежние строки? Ответ на это влияет и на структуру, и на сроки, и всплывает он обычно на миграции.
дальше
Теорию прочитали. Навык ставится повторением
В Сеньорчике эта подтема идёт в ежедневных сессиях: движок возвращает её, пока ответы не станут уверенными, и ведёт прогресс отдельно по каждой подтеме. Теория внутри тоже бесплатна, лимит только на количество вопросов в день.