Привет!
Меня зовут Коля, и я системный аналитик.
В большинстве источников моделирование данных (в контексте создания приложений) рассматривается как последовательное создание трёх моделей данных - концептуальной, логической и физический. Такого порядка придерживаются, например, DMBOK2 и BABOK, а также многочисленные статьи в сети Интернет.
Рискну предложить несколько дополнений и уточнений к этому процессу - как на основании собственного опыта, так и обобщения опыта коллег, с которыми обсуждал этот вопрос.
Дополнение 1. Разделение модели данных предметной области и модели данных приложения
При переходе от логической к физической модели происходит революция - меняется объект моделирования.
Концептуальная и логическая модели составляются для предметной области. Сущности данных моделей - это понятия предметной области.
Физическая модель составляется для базы данных приложения. Сущность физической модели - это таблица (или другая структура данных в зависимости от типа СУБД).
Поэтому не совсем корректно рисовать это как единый процесс, более точно будет так:
Почему это так важно? Потому что меняется почти всё - и цель, и количество моделей, и участники, и даже зачастую инструмент и нотация.
Всегда лучше уточнять - что именно отражает модель, предметную область или базу данных приложения.
Что именно меняется?
Меняется цель
Модель данных предметной области составляется для (основные цели):
Чтобы самим разобраться в предметной области.
Чтобы верифицировать своё понимание предметной области с заказчиком или доменными экспертами.
В некоторых случаях - чтобы сформировать единый понятийный аппарат. Слово "клиент" неоднозначно, а "сущность логической модели Клиент" имеет вполне конкретную семантику. Но чаще для этого используют глоссарий.
Создание модели данных приложения - это просто часть разработки. Если в приложении есть база данных, то её нужно спроектировать, иначе она ниоткуда не появится.
Меняется кратность
Если концептуальная и логическая модели соотносятся друг с другом как 1:1 (т.к. объект моделирования один и тот же), то связь между логической и физической - скорее many-to-many.
Приложение может иметь несколько БД - например, часть данных хранится в РСУБД, часть в NoSQL. Логично сделать две разные модели данных для двух физически обособленных БД.
Или система может состоять из нескольких приложений, у каждого из которых своя БД. При этом вся система реализует функциональность в одной предметной области. Логично составить одну модель данных предметной области и несколько моделей данных приложений.
Приложение может включать в себя функциональность в разных предметных областях. Это характерно, например, для ведомственных систем организаций с несколькими видами деятельности (ФНС России регистрирует юрлица и собирает налоги - совершенно разные виды деятельности). Например, мне известна одна организация которая занимается поставкой автозапчастей и изготовлением женских сумок, и при этом внедряет единую ERP. Странно рисовать одну модель предметной области для автозапчастей и для сумок - между ними нет ничего общего.
Меняются участники
Модель данных предметной области составляет, как правило, бизнес-аналитик (или фуллстек-аналитик, если эта роль совмещается с системным аналитиком).
Модель данных приложения - архитектор БД, бекенд-разработчик или реже системный аналитик.
Сравнительно редко в одной голове совмещается и знание предметной области, и знание конкретной СУБД на уровне достаточном для качественного проектирования БД.
Меняется нотация
Для создания модели данных предметной области чаще используют те или иные виды ER-диаграмм - например, в нотации Crow's foot или Min-Max. Иногда используют и UML Class Diagram, хотя о корректности этого можно спорить. Но в любом случае это модель "сущность-связь".
DMBOK2 приводит пример "многоуровневой концептуальной модели данных". - это не сущность-связь. При этом на практике я ни разу с использованием иных видов моделей для концептуального моделирования не сталкивался.
Если у вас есть иной опыт, напишите в комментариях.
Нотация модели данных приложения зависит от типа БД - для документной и для реляционной СУБД используются совершенно разные нотации.
Меняются инструменты
Модель данных предметной области составляется в основном в иллюстративных целях. Вполне приемлемо использовать для этого не только специализированные средства моделирования, но и любые другие инструменты - то же Visio или Miro. Выглядеть будет так же, составлять проще.
Физическая модель данных должна в итоге превратиться в структуру БД (например, путем преобразования в DDL-скрипты). Странно сперва рисовать где-то модель (как картинку), а потом руками писать скрипты - двойная работа. Разумно использовать инструмент, не приводящий к двойной работе.
При этом, разумеется, можно использовать инструменты проектирования наподобие Enterprise Architect или Power Designer - которые позволяют взаимосвязанно создавать все три модели в одном инструменты.
Также важно отметить, что эти модели часто составляют разные люди. Сложно найти единый инструмент, одинаково удобный как для бизнес-аналитика, так и для бекенд-разработчика.
Дополнение 2. Существование не только логической модели данных предметной области, но и логической модели данных приложения
Классические источники предполагают, что физическая модель (данных приложения) составляется сразу по логической модели (данных предметной области).
Но есть ряд случаев когда это невозможно либо неэффективно, и возникает промежуточное звено - назовём его "логическая модель данных приложения".
Слово "логический" подразумевает отсутствие привязки к конкретной СУБД. Максимум может быть привязка к типу СУБД - реляционная она или например документная.
Слово "приложения" подразумевает, что сущностями в данной модели являются не понятия предметной области, а будущие таблицы БД (или иные сущности в рамках СУБД приложения, если она не реляционная).
Такая модель данных в нужной степени денормализована, обогащена служебными таблицами и полями, в ней указаны типы данных без привязки к СУБД - т.е. "строка до 500 символов" вместо "nvarchar(500)" и обязательность полей.
Также можно обогатить эту модель указанием полей по которым реализуется поиск (чтобы создать индексы) или бизнес-ключей (чтобы создать уникальные индексы).
В некоторых случаях при наличии логической модели данных приложения акт проектирования в отношении физической модели данных приложения может быть вырожденным - либо он осуществлялся непосредственно в процессе разработки, либо он тривиален.
При этом на схеме он отражен - потому что тем или иным образом, но физическая структуры базы данных всё равно появляется.
В каких же случаях возникает "логическая модель данных приложения"? Ниже перечислены четыре случая, которые встречались в моей практике.
Случай 1. Специфика команды
В статье Умный аналитик – глупый разработчик vs. глупый аналитик – умный разработчик приведена ситуация, когда системный аналитик практически единолично занимается проектированием. Такое бывает на практике, и чаще чем хотелось бы.
"Глупый разработчик" не надо понимать буквально - как указание на низкий уровень когнитивных способностей.
Здесь может быть много причин - и узкое понимание границы зоны ответственности разработчика (я тут просто кнопки нажимаю, напишите чётко что делать), и команда разработки из джунов с недостаточным опытом, и временно привлеченные разработчики которые через месяц уйдут на другой проект и не хотят погружаться.
В такой ситуации нельзя просто передать разработчикам на вход логическую модель предметной области и ожидать что она будет корректно имплементирована.
Что делать системному аналитику - если он не является экспертом в СУБД? Можно составить логическую модель данных приложения. "Глупым" разработчикам по ней корректно составить физическую модель гораздо проще.
Случай 2. Использование фреймворка, реализующего принцип "code first"
Как выглядит проектирование физической модели при использовании фреймворка использующего принцип "code first"? Фактически это делает разработчик, когда составляет класс entity и добавляет к нему аннотации. Всё остальное происходит "автомагически".
Подход "code first" - генерация структуры БД по классам.
Такие возможности есть в Entity Framework, JPA2, SQLAlchemy и т.д. На Хабре есть статьи про это, например https://habr.com/ru/post/234827/ и https://habr.com/ru/post/174709/ (случайная выбрал две статьи).
Как системному аналитику участвовать в процессе проектирования модели данных приложения - если исходя из проектной ситуации это необходимо?
Сидеть рядом с разработчиком и вместе с ним проектировать классы и расставлять аннотации? Так себе идея. Да и хочется это сделать заранее, а не прямо во время разработки.
Обсудить заранее с разработчиком и написать большущий комментарий к задаче в Jira? Тоже не очень, несистемно и может потеряться.
Решение - составить логическую модель данных приложения (которая потом практически 1:1 воплотится в классы). Составить её можно как вместе с разработчиком (если он может и готов участвовать в проектировании), так и без него (если он "глупый").
В этом случае модель данных приложения может быть с равным успехом быть представлена как в виде UML Class Diagram (т.к. первичны именно классы), так и в виде ER-диаграммы (т.к. классы соответствуют таблицам).
Случай 3. Приложение поддерживает разные СУБД
Существуют приложения, которые поддерживают разные СУБД. Как правило, в слое данных (data layer) таких приложений реализован дополнительный уровень абстракции, который изолирует приложение от специфики СУБД.
1С: Предприятие, например, поддерживает 5 СУБД. Получается, что одно приложение может иметь 5 разных физических моделей данных. Напрашивается обобщение этих 5 физических моделей данных в виде одной логической - ведь там по сути одни и те же данные. И это тоже будет "логическая модель данных приложения".
Если в каком-то месте (например, в описании алгоритма формирования отчета) нужно сослаться на поле в БД, то можно не указывать 5 разных вариантов для разных СУБД, а один раз указать поле из логической модели данных приложения.
Если коллеги из 1С случайно прочитают этот пост, прошу их уточнить в комментариях - есть у них такая сущность как "логическая модель данных приложения" или нет.
Случай 4. Большой разрыв между моделью данных предметной области и физической моделью данных приложения
Большой разрыв может возникать, например, в случае реализации приложения путем расширения базового продукта (как примеры - Liferay, Sharepoint, Docushare, Alfresco), который уже имеет структуру БД с предусмотренными точками расширения. Или в случае использования фреймворка, который накладывает ограничения на структуру базы данных.
В этом случае структура базы данных и модель данных предметной области имеют между собой очень мало общего.
Данная ситуация затрудняет разработку, эксплуатацию и модернизацию приложения - например, сложно сопоставить между собой атрибут сущности предметной области и поле таблицы БД. Если требование сформулировано в терминах предметной области, то бывает сложно переложить его на реализацию.
Помочь в этой ситуации также может составление логической модели данных приложения.
С одной стороны, она близка к физической модели данных, и без труда позволит перевести требования сформулированные в терминах логической модели данных приложения на таблицы и поля БД.
С другой стороны, для неё описан мэппинг на модель данных предметной области, она документирована и удобна для использования аналитиком.
Дополнение 3. Обязательность моделей данных предметной области
Насколько обязательным этапом является составление моделей данных предметной области?
Концептуальная модель данных предметной области, с моей точки зрения, должна быть всегда. В отдельных случаях она может не документироваться в виде артефакта и существовать только в голове членов команды - например, если в проектировании участвует только системный аналитик и для него это не первый проект в данной предметной области.
Но такой подход имеет много недостатков - тот же bus factor и т.д. Желательно её документировать.
Необходимость составления логической модели данных предметной области, с моей точки зрения, зависит от уровня детализации документа содержащего требования (как бы он ни назывался - ТЗ, SRS, FRD и т.д.).
Если документ достаточно верхнеуровневый, то достаточно концептуальной модели данных предметной области. Если документ подробный, то нужна также и логическая модель данных предметной области.
Если работы по созданию приложения были начаты на основе верхнеуровневых требований (содержащих только концептуальную модель данных), то составление логической модели данных предметной области может быть избыточным: может быть достаточно только логической модели данных приложения.
Получается следующая схема:
Итого
Необходимо различать модель данных предметной области и модель данных приложения.
Концептуальная модель данных - всегда для предметной области, физическая модель данных - всегда для приложения, логическая модель данных - может быть как для предметной области, так и для приложения.
Логическая модель данных приложения зависит от типа СУБД (например, реляционная СУБД и документная СУБД), но не от конкретной СУБД (для PostgreSQL и для Oracle может использоваться одна модель). Физическая модель данных приложения зависит и от типа СУБД, и от конкретной СУБД.
В зависимости от специфики проекта может составляться различный набор моделей данных.
Почти всегда должны составляться: концептуальная модель данных предметной области и одна из логических моделей данных (предметной области или приложения).
Мой личный набор, который я использую в большинстве проектов - концептуальная модель данных предметной области и логическая модель данных приложения.
В моих конкретных условиях он оказался оптимальным по отношения "полученная польза / затраченные усилия".
А какие виды моделей данных составляете вы в своих проектах?
P.S. Дополнение 4. Модель данных микросервиса
У меня был всего один кейс, чего недостаточно для каких-либо выводов. Поэтому разместил этот блок после раздела "Итого". Если у вас есть другой опыт, напишите о нём в комментариях - буду рад о нём узнать.
Модель данных предметной области никак не зависит архитектуры, в том числе наличия или отсутствия микросервисов. Но как организован переход от логической модели к физической в случае микросервисной архитектуре?
Как это было у нас. На этапе сбора требований "по классике" были составлены концептуальная и логическая модели данных предметной области.
После того, как на этапе проектирования были выделены микросервисы и определены зоны их ответственности, была сделана "нарезка" логической модели предметной области - какой микросервис будет хранить какие сущности. Это нужно для того, чтобы передать этот кусок модели (вместе с иными требованиями) той подкоманде, которая будет заниматься микросервисом. Приложение было большим, подкоманд много, некоторые из них субподрядные. Давать всем общую модель было избыточно.
Одна и та же сущность предметной области при "нарезке" могла попасть сразу в несколько микросервисов: например, сведения об организациях были нужны практически во всех микросервисах (с разным реквизитным составом).
Как назвать эту модель? С одной стороны, она остаётся логической моделью предметной области - сущности это понятия предметной области, а не таблицы, уровень детализации соответствует логической модели. С другой стороны, она уже частично привязана к реализации - то есть определён микросервис, в котором эта сущность будет имплементирована.
Таким образом, между логической моделью предметной области и моделью данных приложения (неважно, логической или физической) может существовать еще один промежуточный этап - "логическая модель данных предметной области, планируемая к реализации в рамках компонента архитектуры приложения".