Много определений и точек зрения слышал от коллег и экспертов, но больше всего удивляет, когда используется контекст проектирования баз данных. Это только одна область применения - не стоит ограничиваться этим.
Рекомендую доклад Михаила Максимова на 35 минут на тему уровней моделирования данных - лаконично, просто и с примерами из опыта.
А если нет времени смотреть, то ниже основные тезисы:
Три уровня моделирования сущностей: 🔹Концептуальный - сущности на верхнем уровне абстракции, которые используются в бизнес-процессах, бизнес-сервисах, при описании продуктов и услуг;
🔹Логический - сущности обрабатываются в рамках информационной системы
🔹Физический - сущности, обусловленные особенностями реализации логической модели на определенной технологической платформе.
Примеры методов моделирования:🔹Концептуальный - Mind Map;
🔹Логический - ER model, Class Diagram;
🔹Физический - XML Schema.
Зоны ответственности:🔹Системный аналитик - логический уровень;
🔹Бизнес-аналитик - концептуальный;
🔹Архитектор системы - логический и физический.
Перед тем как собирать требования с заказчиков проекта, которые обычно являются руководителями своих подразделений, нужно выровнять терминологию - через концептуальную модель. Первая версия может состоять из терминов локальных нормативных актов (ЛНА) - в основе фрагменты концептуальной модели (предметная область слишком большая). Фрагменты позволили выявить смежные области -> определить дополнительные заинтересованные стороны -> доработать модель.Сначала изменили подход бизнеса через моделирование ЛНА, а потом под это сделали решение. Идеально, если информационная модель станет основной для новых версий ЛНА.
Наибольшую ценность представляет не набор моделей разных уровне, а трассировка между ними - где проходят коммуникации между разными ролями.Нормально, если одна логическая сущность системы реализует 2 и более концептов - аналогично в обратную сторону.
Трассировка моделей - взаимовыгодная история. Системный аналитик может проверить реализуемость концептуальной модели (определенной с заказчиками) в рамках заданного бюджета и ограничений текущей системы (на логическом и/или физических уровне), архитектор - убедиться в корректности решений (изучая концептуальную модель) с точки зрения масштабирования и прочего.Поставьте, пожалуйста, реакцию 🔥, если пост оказался полезным.
