Что отображает ER-диаграмма
Что проверяют
Умеете ли вы читать и рисовать модель данных так, чтобы по ней можно было спроектировать базу. Аналитика спрашивают об этом, потому что ER-диаграмма это основной способ договориться о структуре данных до того, как её напишут в коде.
Как отвечать
Диаграмма показывает структуру данных предметной области: из чего она состоит и как части связаны. На ней есть:
- сущности: то, о чём мы храним сведения, например сотрудник, заказ, позиция заказа;
- атрибуты: свойства сущности, среди них ключевые, по которым экземпляр опознаётся;
- связи с двумя характеристиками: мощность, то есть один к одному, один ко многим, многие ко многим, и обязательность с каждой стороны;
- слабые сущности, которые не существуют без родителя, как позиция без заказа.
Полезно разделить уровни. Концептуальный работает понятиями бизнеса, логический добавляет ключи и типы и разрешает связь многие ко многим через промежуточную сущность, физический уже говорит про таблицы, индексы и типы конкретной СУБД. В нотации «воронья лапка» мощность и обязательность читаются прямо на концах линии, поэтому её удобно показывать заказчику.
Скажите и о границах: диаграмма описывает состояние данных, а не поведение. Порядок шагов, статусы процесса и обмен сообщениями рисуются другими нотациями, и мешать их в одну картинку не стоит.
Где спотыкаются
Рисуют процесс. На схеме появляются стрелки «сначала это, потом то», и получается смесь модели данных с потоком работ, из которой нельзя вывести ни таблицы, ни ограничения целостности.
Второе: оставляют связь безымянной линией без мощности и обязательности. Именно там прячутся главные вопросы к заказчику: бывает ли заказ без позиций, может ли у клиента быть несколько адресов, что делать с историей изменений.
Третье: не разрешают связь многие ко многим и не показывают ключи. Промежуточную таблицу разработчик всё равно заведёт, но атрибуты самой связи, вроде количества и цены на момент покупки, придумает сам, а аналитик потом удивится расхождению.