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