Концептуальная, логическая или концептуально-логическая модель данных?

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

Рекомендую доклад Михаила Максимова на 35 минут на тему уровней моделирования данных - лаконично, просто и с примерами из опыта.

А если нет времени смотреть, то ниже основные тезисы:

➡️Три уровня моделирования сущностей:
🔹Концептуальный - сущности на верхнем уровне абстракции, которые используются в бизнес-процессах, бизнес-сервисах, при описании продуктов и услуг;
🔹Логический - сущности обрабатываются в рамках информационной системы
🔹Физический - сущности, обусловленные особенностями реализации логической модели на определенной технологической платформе.
➡️Примеры методов моделирования:
🔹Концептуальный - Mind Map;
🔹Логический - ER model, Class Diagram;
🔹Физический - XML Schema.

➡️Зоны ответственности:
🔹Системный аналитик - логический уровень;
🔹Бизнес-аналитик - концептуальный;
🔹Архитектор системы - логический и физический.

➡️Перед тем как собирать требования с заказчиков проекта, которые обычно являются руководителями своих подразделений, нужно выровнять терминологию - через концептуальную модель. Первая версия может состоять из терминов локальных нормативных актов (ЛНА) - в основе фрагменты концептуальной модели (предметная область слишком большая).

➡️Фрагменты позволили выявить смежные области -> определить дополнительные заинтересованные стороны -> доработать модель.

➡️Сначала изменили подход бизнеса через моделирование ЛНА, а потом под это сделали решение.
Идеально, если информационная модель станет основной для новых версий ЛНА.

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

➡️Трассировка моделей - взаимовыгодная история. Системный аналитик может проверить реализуемость концептуальной модели (определенной с заказчиками) в рамках заданного бюджета и ограничений текущей системы (на логическом и/или физических уровне), архитектор - убедиться в корректности решений (изучая концептуальную модель) с точки зрения масштабирования и прочего.

Поставьте, пожалуйста, реакцию 🔥, если пост оказался полезным.