Представляет ли диаграмма классов структуру базы данных?

Question

Я впервые запускаю целый проект сам, и я застрял между UML-моделированием (диаграмма классов) и структурой базы данных.

Должен ли я использовать те же классы, которые я моделирую на диаграмме классов в базе данных?

Например, у меня есть два User, Service_provider и Client. На диаграмме классов я рассматриваю каждый из них как уникальный класс. Но я решил использовать наследование одной таблицы в базе данных, поэтому я храню обоих пользователей в одной таблице и добавляю в нее атрибут роли.

Действует ли моя модель в этом случае? или мне просто нужен один класс для User? (но в этом случае я не могу показать связь между Service_provider и Client, поскольку Service_provider может иметь много Clients)

Может кто-нибудь объяснить мне, пожалуйста?

Answer 1

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

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

Поэтому я настоятельно рекомендую оставить оба:

1. истинными модель дизайна, которая показывает классы такими, какими вы их видите;
2. модель базы данных с таблицами для документирования сопоставления ORM . Для этого вы можете использовать профиль базы данных для UML, чтобы добавить «table» стереотип

В чистом моделировании БД также обычно различают guish логическое модель (сущности, отношения) и физическая модель (таблицы, реализующие логическую модель) по аналогичным причинам.

Примеры:

• наследование одной таблицы , объясненное Мартином Фаулером
• и ответ на другой вопрос о моделировании базы данных с помощью UML

Answer 2

В двух словах (и, как мы обсуждали в комментариях), ваша модель верна и хороша:)

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

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

Answer 3

Разработка приложения поддерживается полным набором (развивающихся) моделей, как показано на диаграмме ниже.

Три основные цели создания моделей классов UML при разработке приложения:

1. Описание типов сущностей проблемной области приложения для анализа и лучшего понимания требований к приложению в концептуальной (доменной) модели .
2. Разработка схемы базовая база данных приложения (обычно это RDB-схема, определенная с помощью набора операторов CREATE TABLE).
3. Проектирование классов модели модели данных вашего приложения, которое будет закодировано, например, как Java классы сущностей или C# классы с аннотациями EF.

Для 1 и 2 вы можете взглянуть на мой книга Введение в информационное моделирование и базы данных , а для 3 вы можете проверить книгу по разработке на основе моделей, например, для Java Backend Apps или JavaScript Fronte и приложения .

Answer 4

Хотя существующие ответы уже описывают проблемную область, я хочу добавить, что независимый дизайн класса и модели базы данных (обе получены из модели абстрактного анализа) со временем будут развиваться. Некоторые инструменты поддерживают трансляцию и отслеживание моделей, но я бы не стал доверять им слишком далеко. Лучше иметь индивидуальную прослеживаемость и хорошие механизмы для синхронизации моделей. Это может быть сложно со временем и требует тщательного анализа поверх любого моделирования.