ER-диаграммы: для чего системные аналитики строят модели данных и как это делать

Прежде чем разрабатывать программное обеспечение для заказчика, системному аналитику нужно выстроить ER-диаграмму: понять все элементы системы и определить, как они связаны между собой. Необходимо сначала выстроить всю схему в голове, понять ее, а уже потом разрабатывать конкретные инструменты и IT-решения. Что из себя представляет ER-диаграммы, и почему умение их выстраивать нужно не только айтишникам?

Что такое ER-диаграмма

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

Например, прежде чем создавать ПО для онлайн-сервиса по бронированию отелей, необходимо понять, какая информация будет использоваться и как она соотносится между собой.

В ER-диаграмме есть 2 типа элементов:

• Сущности.

Это так называемые термины проекта или понятия. В нашем примере экземплярами сущности «Отель» являются названия всех отелей, с которыми сотрудничает сервис, «Дата» – конкретный период времени, на которое будет бронироваться отель и пр. Также можно выделить такие сущности, как «Номер», «Гость» или «Заказчик» и так далее.

• Атрибуты.

Это второй тип данных, который отражает конкретные характеристики каждой сущности. Для «Отель» атрибутами будут адрес, номер телефона, электронная почта и пр. Для «Гость» – ФИО, паспортные данные, контактная информация. Для «Номер» – порядковый номер, категория и тип.

Атрибуты каждой сущности одинаковые, но значения у них будут разные. То есть у каждого отеля есть один и тот же атрибут, например, «адрес». Но сами адреса будут индивидуальными. У каждого гостя будет необходимый атрибут «ФИО», но данные будут разными.

Когда собраны все сущности и прописаны их атрибуты, наступает следующий этап составления ER-диаграммы – определяется тип связи между элементами (модель «сущность-связь»). Можно выделить 3 разных типа такой связи:

• «один-к-одному» или «1:1» – одна сущность связана только с одной другой сущностью;

• «один-ко-многим» или «1:N» – одна сущность связана со множеством других сущностей;

• «многие-ко-многим» или «M:N» – множество сущностей связано с другим множеством сущностей.

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

И все эти взаимосвязи и элементы системы отражает ER-модель, позволяющая понять саму структуру работы того или иного проекта. А понимание структуры – это залог успешного создания и внедрения ПО, которое будет ее реализовывать.

Типы ER-моделей

• Концептуальный.

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

Например, в случае работы с транспортной компанией, нужно выделить сущности: «Накладная», «Водитель», «Маршрут», «Транспортное средство», «Груз» и пр.

• Логический.

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

Например, атрибуты сущности «Водитель» – ФИО, паспортные данные, номер водительского удостоверения, категория, контактные данные и пр. А атрибуты сущности «Транспортное средство» – марка, пробег, регистрационный номер, грузоподъемность и пр.

• Физический.

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

Применение ER-диаграмм

Но если вам необходимо программное обеспечение для более сложной структуры данных, то без четкой модели не обойтись.

Чаще всего ее применяют, когда:

• разрабатывается новый проект и пока нет четкого понимания, какие данные в нем будут задействованы и как они будут соотноситься между собой;

• необходимо внедрить решение для автоматизации уже работающего проекта с учетом всех его характеристик, особенностей и массива данных;

• появилась необходимость создать и внедрить новую базу данных или таблицу в уже существующее и применяемое ПО.

Важно понимать, что разработка ER-модели не привязана к какой-то определенной сфере деятельности компании или ниши, для которой создается ПО. ER-диаграмма – это универсальный инструмент работы с данными, он может применяться в совершенно любой отрасли и направлении деятельности компании.

Более того, создание ER-модели порой не связано с разработкой или подбором определенного IT-решения. Она помогает понимать и управлять организационными и бизнес-процессами, структурировать и систематизировать работу над различными проектами, систематизировать информацию, заниматься исследовательской работой и пр.

Символы и нотации ER-диаграмм

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

Разберем 2 самые популярные и простые нотации: Чена и Мартина.

Нотация Чена

В нотации Чена сущность отражается в прямоугольнике, атрибут в овале, а связь в ромбе. Над линиями, которые отображают связь, ставится символ, характеризующий ее тип: «1:1», «1:N», «M:N».

Нотация Мартина

Она прекрасно подходит для построения диаграммы на логическом уровне, потому что более компактна. «Сущность» также вписывается в прямоугольник, как и в нотации Чена. А вот все остальное отличается. Во-первых, атрибуты помещаются сразу под сущностью и включены в общую диаграмму. А связи между сущностями не подписываются, а обозначаются специальными линиями.

Эти линии могут применяться в разных комбинациях. Например, в ресторане к каждому конкретному столу прикреплен лишь 1 официант, а другие этими посетителями не занимаются. Связь от стола до официанта «один и только один». Но, в то же время, за одним официантом закреплено сразу несколько столов. Связь от конкретного официанта к столам «ноль или много», то есть он может вообще не заниматься посетителями (если их нет за закрепленными за ним столами), либо обсуживать сразу несколько клиентов за разными столами.

Вот так будет выглядеть ER-модель в нотации Мартина:

Как создать простую ER-диаграмму

Когда есть понимание, что такое ER-модель, как она логически устроена и для чего нужна, составить ее достаточно просто. Главное шаг за шагом переходить от одного пункта к другому:

• Определение всех сущностей.

Это этап, на котором создается концептуальная модель диаграммы. Чтобы ее сформировать, требуется поговорить с заказчиком, понять суть проекта, пообщаться со всеми пользователями будущего программного обеспечения, сформировать понимание этапов их работы.

• Определение атрибутов для каждой сущности.

На этом этапе начинается детализированный анализ информации, выявляются ключевые характеристики отдельной сущности. Должно сформироваться понимание того, по каким значениям она будет идентифицироваться.

• Определение связей между сущностями.

Необходимо понять, какие из них в принципе взаимодействуют между собой, а какие – нет. Например, между «Гостем» и «Отелем» есть связь, как и между «Номером» и «Датой». А вот между «Номером» и «Номером» в разных отелях – нет.

• Определение типа связи между сущностями.

То есть нужно понять, каким будет взаимодействие: «1:1», «1:N» или «M:N». Второй этап в этом пункте – установление статуса сущности в одной связке: родительская или идентифицирующая. Например, речь идет о сети отелей, то есть существует, допустим, 3 филиала. В каждом из них по 200 номеров. Конкретный отель – родительская сущность, а номер – идентифицирующая, потому что невозможно использовать сущность «Номер» без уточнения «Отеля».

• Проверка правильности составления ER-диаграммы.

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

Примеры ER-диаграмм

Зная «язык» выстраивания ER-модели, можно не только научиться «читать» итоговые диаграммы, но и начать самостоятельно их конструировать. Вернемся к примеру с бронированием отелей. Известны «сущности», тип связи между ними и «атрибуты» для каждой из них.

Если использовать нотацию Чена, то диаграмма будет выглядеть следующим образом:

В этой нотации она достаточно усложняется, особенно, если делать ее на логическом уровне. Тут появляются новые обозначения. Во-первых, определяется родительская и дочерняя сущность. Для последней необходим прямоугольник, к которому добавляется вторая рамка. Во-вторых, в этом подходе ассоциативная связь по типу становится самостоятельной сущностью и обозначается ромбом внутри прямоугольника. И чем больше добавляется атрибутов, тем больше будет расти диаграмма.

Именно поэтому для логического уровня ER-модели, чаще используют нотацию Мартина, ведь она более компактна и лаконична, хотя требует лучшего знания схем, по которым отражаются связи между сущностями. Такая диаграмма приобретает следующий вид:

Суть в этих 2 примерах одинаковая, а графический язык, с помощью которых она передается, имеет значительные различия.

Что в итоге

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

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

При этом, чтобы составить ER-модель, не нужно специальных программ или знаний, достаточно применить логику и элементарный графический редактор. Но, если массив данных огромен, если нужно разрабатывать и внедрять сложные, а порой и уникальные IT-инструменты, то лучше обратиться за помощью к опытным специалистам. Это поможет ускорить процесс, избежать ошибок в составлении ER-модели и значительно повысить ее результативность.