LeadStartup
Получите бесплатно — все материалы с наших курсов
Тренинги, Курсы, Обучение — Agile, Scrum, OKR
Тренинги, Курсы, Обучение — Agile, Scrum, OKR
Тренинги, Курсы, Обучение — Agile, Scrum, OKR
Egor Sevryugin
Mikhail Ryazhenka
Mikhail Ryazhenka
Founder, Executive Partner

Полное понимание ER-модели: от основ до практического использования. Узнайте, как эффективно применять ER-модели для анализа и проектирования баз данных.

Статья может быть полезной для системных-, бизнес–аналитиков, а также смежных профессий, в которых требуется понимание состава сущностей и связи между ними в той предметной области, в которой ведется работа.

Построение Entity-Relationship, или ER-модели

Текст может быть полезен для системных-, бизнес–аналитиков, а также смежных профессий, в которых требуется понимание состава сущностей и связи между ними в той предметной области, в которой ведется работа.

Для системных аналитиков необходимость такой экспертизы очевидна, а для бизнес–аналитиков я поясню.

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

Что такое ER-модель

ER–модель — это модель вида «сущность–связь». На модели в графическом виде отображаются:

  • сущности предметной области, их атрибуты

  • связи между сущностями: отношение между сущностями, множественность.

Рисунок. ER–диаграмма, описывающая сущности, относящиеся к товарно–складской деятельности

Процесс построения ER–диаграммы позволяет выявить сущности, взаимосвязи между ними, и построить в итоге логическую модель базы данных процесса.

Построение ER-модели для больницы

Представим, что нам нужно разработать информационную систему, ИС, для автоматизации работы поликлиник.

В поликлиниках ведется запись пациентов к врачам–специалистам. ИС должна поддерживать эту работу регистратуры. На приеме у врача пациенту ставится диагноз по его жалобе. На приеме пациенту может быть:

  • выписан (открыт) или закрыт больничный лист,

  • выписано направление на лечение в районную (областную) больницу.

По результату приема пациента медицинская сестра в регистратуре (по документам, предоставленным врачом, в конце рабочего дня) или сам врач (в своем кабинете) вносит в ИС данные о приеме данного пациента. По направлению на лечение проводится прием в больницу. Пациент размещается в соответствующем (диагнозу) отделении больницы, ему выделяется больничная койка (койко–место). После прохождения лечения пациент выписывается из больницы и направляется в поликлинику, где ему закрывают (или продлевают) больничный лист.

ИС должна регистрировать поступление и выписку пациентов по отделениям больницы.

Информационная система должна поддерживать ответы на следующие запросы (за текущий период): • Сколько пациентов обратилось в поликлиники района? • По каждому типу болезни, сколько новых диагнозов поставлено? • Сколько больничных листов выдано по данному типу заболевания? • Сколько койко–мест свободно (занято) в каждом отделении районной больнице на данное число? • Какова загруженность врачей данной специальности по поликлиникам района?

Выявление сущностей предметной области

Выписываем все сущности предметной области в список:

  • пациент,

  • запись к врачу,

  • прием у врача,

  • врач–специалист,

  • специальность врача,

  • диагноз,

  • тип болезни,

  • больничный лист (Б/Л),

  • открытие Б/Л,

  • закрытие Б/Л,

  • поликлиника,

  • больница,

  • отделение больницы,

  • направление в больницу,

  • поступление в больницу,

  • выписка из больницы.

Следующим шагом определяем, какие из этих сущностей зависят от времени, а какие–нет. Те сущности, что не зависят от времени, назовем сущностями–справочниками, а зависящие от времени — сущностями–событиями.

Список сущностей–справочников:

  • пациент,

  • врач–специалист,

  • специальность врача,

  • диагноз,

  • тип болезни,

  • больничный лист (Б/Л),

  • поликлиника, больница,

  • отделение больницы.

Список сущностей–событий:

  • запись к врачу,

  • прием у врача,

  • открытие Б/Л,

  • закрытие Б/Л,

  • направление в больницу,

  • поступление в больницу,

  • выписка из больницы

Для каждого события выявляем его «участников» из числа справочников и строим диаграмму классов. Для этого отвечаем на вопрос: «информацию о каких справочниках должно «знать» событие?

Запись к врачу. Событие связано с (1) пациентом, который записывается, (2) – с врачом и с поликлиникой

Рисунок. Событие «Запись к врачу».

В дальнейшем эта диаграмма будет нуждаться в реорганизации, т.к. врач связан с поликлиникой и событие «запись к врачу» будет связано с поликлиникой через врача.

Связь врача с поликлиникой.

Прием у врача. Событие связано с (1) пациентом, (2) – с врачом, (3) – с диагнозом, на приеме может быть выписан/продлен/закрыт больничный лист, т.е. (4) – с больничным листом —

Рисунок. Событие «Прием у врача».

События открыть/закрыть больничный лист связаны с событием «Прием у врача». На приеме врач может принять решение о госпитализации пациента, т.е. произойдет событие «направление в больницу»:

Поступление в больницу. Событие связано с пациентом, с отделением больницы и с диагнозом

Рисунок. Событие «Поступление в больницу».

Выписка из больницы. Событие связывается с «поступлением в больницу» и через него связывается с пациентом, диагнозом и отделением.

Если перенести сущности в одну диаграмму, получится такая схема:

Реструктурируем связи. Снимаем связь «запись к врачу» — «поликлиника», т.к. она идентифицируется через врача–специалиста. «Запись к врачу» удалим, будем считать её как запись «прием у врача», у которой отсутствует время приема. Таким образом, «прием у врача» имеет атрибут «состояние» с двумя значениями: «запись» (приема еще не было) и «прием» (прием у врача уже состоялся). Для диагноза используем дополнительную классификацию (сущность) «тип болезни», а для врача, – классификацию, – «специальность». Результат реструктуризации в виде сводной диаграммы классов:

Множественность

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

Рисунок. Сводная диаграмма классов (модель «сущность–связь») с проставленными множественностями

Материал подготовлен на основе методички «Базы данных и процессы их создания» Михаила Кумскова, преподавателя МГУ имени Ломоносова