Что выбрать для проектирования БД:
сравнение UML-диаграммы классов и ER-диаграммы

Часто у системных аналитиков возникает путаница:
Что использовать для проектирования БД - диаграмму классов UML или ER-диаграмму?
Вопрос с подвохом, хорош для собеседований.

Эта статья создана для тех, кто хочет понять суть различий диаграммы классов UML или ER-диаграммы, и определить, для каких целей используется каждая из них.

Примеры в статье связаны с разработкой системы для онлайн-зоомагазина, проектирование базы данных для которого я показала в Telegram-канале.

Диаграмма классов UML

Это графическое представление структуры программного кода системы, создаваемой согласно принципам объектно-ориентированного программирования (далее - ООП), которое показывает классы, их атрибуты, методы и взаимосвязи между ними.

Элементы:

Классы программного кода (представлены прямоугольниками).
Атрибуты (свойства / переменные) программного кода (находятся внутри прямоугольника класса, сверху).
Методы программного кода (находятся внутри прямоугольника класса, снизу).
Взаимосвязи (стрелки между классами: ассоциация, наследование и др.).

Назначение:

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

Пример:

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

ER-диаграмма (Entity-Relationship Diagram)

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

Элементы:

Сущности (представлены прямоугольниками).
Атрибуты (находятся внутри прямоугольника сущности).
Связи (стрелки между сущностями).

Назначение:

Помогает разработчикам и аналитикам создавать и описывать структуру БД.

Пример: У нас есть сущность "Пользователь" с атрибутами "имя" и "электронная почта". Эта сущность связана с сущностью "Заказ", который включает в себя номер, дату оформления, а также связан с различными товарами. Методов нет.

Еще больше примеров можно найти по этой ссылке - в постах Telegram.

Отличия сущностей на ER-диаграмме от классов в UML

Отличия сущностей на ER-диаграмме от классов на UML диаграмме классов заключаются в их предназначении.

Сущности ER-диаграммы:
Представляют объекты реального мира и абстрактные объекты, которые имеют значение для базы данных.
Содержат только информацию о данных (атрибуты) и их отношениях (связи между сущностями).

Классы UML:
Представляют абстракции объектов в программном коде, включая их атрибуты (свойства / переменные) и методы (функции).
Описывают структуру объекта, его атрибуты и методы, а также могут включать информацию о наследовании, интерфейсах, зависимостях - обо всем, что связанно с ООП.

Сущности в БД и соответствующие классы в коде могут отличаться.

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

Отличия диаграммы классов UML от ER-диаграммы

Фокус:
UML-диаграмма классов сфокусирована на структуре кода программы, ER – на структуре базы данных.

Использование:
UML-диаграмма классов применяется в объектно-ориентированной разработке, ER-диаграмма – при проектировании баз данных.
По факту, в реальных проектах UML-диаграмму классов не используют. Это избыточная документация, которая меняется в процессе разработки программного кода. При большом желании можно автоматически создать UML-диаграмму на основе кода, но такой потребности у нас пока ни разу не возникало.

Семантика:
UML-диаграмма классов имеет богатый набор отношений (наследование, ассоциация, агрегация и др.), в то время как ER-диаграмма обычно ограничивается типами отношений (один-ко-многим, многие-ко-многим и т.д.).
UML-диаграмма классов имеет методы, в то время как ER-диаграмма их не содержит, т.к. описывает только данные в БД, но не операции над ними.

Если вам всё еще кажется, что нет разницы - UML-диаграмма классов или ER-диаграмма базы данных, то давайте взглянем в инструмент для работы с диаграммами Draw.io. Это разные группы элементов.

Можно ли использовать UML-диаграмму классов для проектирования БД согласно нотации?

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

Вот несколько ключевых моментов, как это может быть реализовано:

1. Классы в UML могут быть интерпретированы как таблицы в БД.
Например, класс "Пользователь" может стать таблицей "Пользователь" в базе данных.

2. Атрибуты классов могут быть интерпретированы как поля (или столбцы) таблицы БД.
Если у нас есть класс "Пользователь" с атрибутами "имя" и "телефон", эти же атрибуты могут стать столбцами в таблице "Пользователь".

3. Ассоциации между классами могут быть интерпретированы как внешние ключи или связи между таблицами.
Например, если класс "Пользователь" связан с классом "Заказ", это может означать, что в БД будет связь между таблицами "Пользователь" и "Заказ" через внешний ключ.

4. Множественность ассоциаций (как 1:1, 1:N, N:M) также может быть отражена при проектировании БД.
Например, если один пользователь может создать много заказов, это может быть отражено как отношение один-ко-многим на ER-диаграмме БД.

Тем не менее, стоит отметить, что для проектирования баз данных более подходяща нотация моделирования это ER-диаграмма (Entity-Relationship diagram). Она создана специально для описания структуры баз данных.

Использовать UML для проектирования БД можно, но нужно понимать его ограничения в этом контексте и быть готовым к некоторым компромиссам или дополнительным шагам преобразования.

А там вроде в UML еще диаграмма объектов была. Можно ее для описания БД использовать?

Диаграмма объектов в UML — это разновидность диаграммы классов, но с акцентом на конкретных экземплярах классов (то есть объектах) и их взаимоотношениях в определенный момент времени. Она представляет снимок системы в конкретный момент времени.

Пример диаграммы объектов для онлайн-магазина:

Объекты:
1. Пользователь: Пользователь1 (имя: "Иван", email: "ivan@example.com")
2. Товар: Товар1 (название: "Дом для кота", цена: 50000 руб.)
3. Корзина: Корзина1 (сумма: 50000 руб.)
4. Заказ: Заказ1 (номер: 001, статус: "В обработке")
Связи:
1. Пользователь1 связан с Корзина1: это его текущая корзина.
2. Товар1 находится в Корзина1: пользователь добавил этот товар в корзину.
3. Пользователь1 связан с Заказ1: это его последний заказ.
4. Товар1 связан с Заказ1: этот товар был заказан.

@startuml

object "Пользователь1" as User1 {
   имя: "Иван"
   email: "ivan@example.com"
}

object "Товар1" as Product1 {
   название: "Дом для кота"
   цена: 50000 руб.
}

object "Корзина1" as Cart1 {
   сумма: 50000 руб.
}

object "Заказ1" as Order1 {
   номер: 001
   статус: "В обработке"
}

User1 --> Cart1 : Имеет
User1 --> Order1 : Сделал
Cart1 --> Product1 : Содержит
Order1 --> Product1 : Включает

@enduml

Использование диаграммы объектов для проектирования баз данных не является стандартной практикой. Однако она может быть полезной в следующих ситуациях:

1. Иллюстрация примеров данных: Если вы хотите показать, какие конкретные данные (объекты) находятся в вашей системе в определенный момент времени, диаграмма объектов может быть полезной. Это может помочь в понимании, какие данные будут храниться в БД.

2. Понимание взаимоотношений: Если у вас сложные отношения между данными и вы хотите иллюстрировать их на примерах, диаграмма объектов может помочь.

3. Тестирование и проверка: Используя диаграмму объектов, можно создавать "сценарии" или "случаи использования" для проверки того, правильно ли ваша база данных или система будет реагировать на конкретные наборы данных.

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

Диаграмма объектов UML может быть использована в качестве дополнительного инструмента при проектировании баз данных, особенно если вы хотите иллюстрировать конкретные примеры данных или взаимоотношений. Однако она не является заменой ER-диаграммы.

Заключение

ER-диаграмма для проектирования баз данных. В ней таблицы (сущности), поля (свойства сущностей) и отношения между таблицами БД.

UML-диаграмма для описания струткуры кода. В ней классы (описывают группы однотипных объектов, как сущности), поля (свойства сущностей), методы (функции - что можно делать с объектами классов) и отношения между классами.

Екатерина Ананьева,
Основатель IT-школы системного анализа
и проектирования GetAnalyst

5 октября 2023

Что выбрать для проектирования БД: сравнение UML-диаграммы классов и ER-диаграммы