📝Моделируем схему данных: ERD против диаграммы классов
🤔 Как-то так получается, что второй пост подряд у меня получается в виде противопоставления двух подходов (осталось только определить, кто антагонист в этой пьесе). Предлагаю сегодня сравнить ERD (Entity-Relationship Diagram) и UML Class Diagram, ведь они так похоже выглядят. Почему мне кажется это интересным? Да просто при проектировании любого нового сервиса/микросервиса/мини-мили-сюси-пуси-сервиса одним из первых шагов будет определение объектов, которые будут участвовать в движухе, и связях между ними.
Таким образом мы подошли к первому вопросу: что общего между ERD и диаграммой классов?
1⃣Обе диаграммы представляют собой структуру данных;
2⃣Там есть прямоугольнички. 🗓 ...и стрелочки (хотя не совсем уж и стрелочки, а скорее связи). ↔️
Что касается различий, то начать нужно с конечной цели:
➡️ERD фокусируется на данных, которые нужно хранить, и их связях в реляционной модели. Иными словами отвечает на вопрос о том, какие данные мы сохраняем, как они связаны и как обеспечить их целостность.
➡️Class Diagram описывает структуру программы, её логические компоненты и их взаимодействие в рамках парадигмы ООП. Иллюстрирует, как будут организованы наши объекты, что они будут уметь делать и как они будут общаться.
Ну, вроде как и то и то нужно и полезно... Но лично мне кажется, что использовать оба эти инструмента при проектировании избыточно и лично я уделяю особое внимание именно данным и их отражению в БД.
Чуть деталей:
🟢Объекты: в ERD сущность, например, User (таблица с полями id, name). В Class Diagram соответственно класс — User (класс с полями id, name и методами createOrder(), getActiveOrders());
🟢Связь: в ERD User ---< Order (один-ко-многим, FK в orders.user_id), в Class Diagram User ---> Order (ассоциация: пользователь имеет заказы);
🟢Объекты уровня ниже: у ERD есть поля в таблицах (total_amount DECIMAL в таблице orders), в диаграмме классов атрибуты и методы: total_amount: fLoat + метод calculateTotal() в классе Order;
🟢Ах да, а еще в диаграмме классов у нас есть наследование.
И вот этот последний пункт вынуждает меня задаться вопросом, а допустимо ли вообще использовать Class Diagram в проекте, который пишется на Rust? 👩💻 Вопрос этот интересен мне по двум причинам:
1⃣В Rust нет ООП и, соответственно, нет наследования;
2⃣На моем текущем проекте используется Rust.
Отвечая на этот вопрос... Да можно, наверное, кто ж запретит? Было бы желание (у меня нет). Вместо классов будут структуры, методы функциями и т.д. Однако, лично я смысла в этом особо не вижу.
В качестве вывода: Удобнее использовать ERD, если ядро проекта — сложная предметная область с множеством связей, а основная задача — проектирование надежной схемы данных. Диаграмма классов, наверное, лучше подойдет для проектирования сложной бизнес-логики со множеством состояний и поведений, где взаимодействие объектов важнее схемы их хранения.
#SystemAnalysis #DataModeling #ERD #UML #Rust #Архитектура #БД #системныйанализ #BusinessAnalysis
🤔 Как-то так получается, что второй пост подряд у меня получается в виде противопоставления двух подходов (осталось только определить, кто антагонист в этой пьесе). Предлагаю сегодня сравнить ERD (Entity-Relationship Diagram) и UML Class Diagram, ведь они так похоже выглядят. Почему мне кажется это интересным? Да просто при проектировании любого нового сервиса/микросервиса/мини-мили-сюси-пуси-сервиса одним из первых шагов будет определение объектов, которые будут участвовать в движухе, и связях между ними.
Таким образом мы подошли к первому вопросу: что общего между ERD и диаграммой классов?
1⃣Обе диаграммы представляют собой структуру данных;
2⃣Там есть прямоугольнички. 🗓 ...и стрелочки (хотя не совсем уж и стрелочки, а скорее связи). ↔️
Что касается различий, то начать нужно с конечной цели:
➡️ERD фокусируется на данных, которые нужно хранить, и их связях в реляционной модели. Иными словами отвечает на вопрос о том, какие данные мы сохраняем, как они связаны и как обеспечить их целостность.
➡️Class Diagram описывает структуру программы, её логические компоненты и их взаимодействие в рамках парадигмы ООП. Иллюстрирует, как будут организованы наши объекты, что они будут уметь делать и как они будут общаться.
Ну, вроде как и то и то нужно и полезно... Но лично мне кажется, что использовать оба эти инструмента при проектировании избыточно и лично я уделяю особое внимание именно данным и их отражению в БД.
Чуть деталей:
🟢Объекты: в ERD сущность, например, User (таблица с полями id, name). В Class Diagram соответственно класс — User (класс с полями id, name и методами createOrder(), getActiveOrders());
🟢Связь: в ERD User ---< Order (один-ко-многим, FK в orders.user_id), в Class Diagram User ---> Order (ассоциация: пользователь имеет заказы);
🟢Объекты уровня ниже: у ERD есть поля в таблицах (total_amount DECIMAL в таблице orders), в диаграмме классов атрибуты и методы: total_amount: fLoat + метод calculateTotal() в классе Order;
🟢Ах да, а еще в диаграмме классов у нас есть наследование.
И вот этот последний пункт вынуждает меня задаться вопросом, а допустимо ли вообще использовать Class Diagram в проекте, который пишется на Rust? 👩💻 Вопрос этот интересен мне по двум причинам:
1⃣В Rust нет ООП и, соответственно, нет наследования;
2⃣На моем текущем проекте используется Rust.
Отвечая на этот вопрос... Да можно, наверное, кто ж запретит? Было бы желание (у меня нет). Вместо классов будут структуры, методы функциями и т.д. Однако, лично я смысла в этом особо не вижу.
В качестве вывода: Удобнее использовать ERD, если ядро проекта — сложная предметная область с множеством связей, а основная задача — проектирование надежной схемы данных. Диаграмма классов, наверное, лучше подойдет для проектирования сложной бизнес-логики со множеством состояний и поведений, где взаимодействие объектов важнее схемы их хранения.
#SystemAnalysis #DataModeling #ERD #UML #Rust #Архитектура #БД #системныйанализ #BusinessAnalysis