«Создай себе досуг, чтобы научиться чему-нибудь хорошему и перестать блуждать без цели.»
 
Консалтинговая компания Марк Аврелий


Концептуальное логическое и физическое моделирование данных

Существует три уровня моделирования данных:

  • Концептуальный -► концептуальная модель
  • Логический -► логическая модель
  • Физический -► физическая модель

 

Концептуальный уровень моделирования

На концептуальном уровне моделирования мы определяем основные понятия предметной области и их взаимосвязь. 

Базовый элемент концептуальной модели: бизнес-сущность.

Примеры бизнес-сущностей:

  • клиент (как вариант, клиент-ФЛ, клиент-ЮЛ),
  • продукт (как вариант, товар, услуга),
  • сделка (как вариант, заказ).

Концептуальная модель наиболее сильно отражается в документах класса ГЛОССАРИЙ. Схематически (графически) наиболее удобным способом отображение концептуальной модели является диаграмма классов. Однако строгие нотации моделирования для концептуального уровня скорее всего окажутся обременением и лучше использовать их на логическом уровне для проверки результирующей модели. Связи между бизнес-сущностями полезно «окрашивать»  действиями из предметной области, например, клиент заключает сделку, заказ состоит из товаров. Наилучшая нотация для концептуального уровня – Archimate (business layer). В данной нотации бизнес-сущности могут быть привязаны к ряду элементов бизнес-слоя, что улучшает их окрашивание или лучше структурирует (делает более наглядной) моделируемую предметную область.

Фокус моделирования: 

  • понятийная/смысловая модель, выработка глоссария
  • создания/проработка представления о понятии/явлении, как об информационном объекте
  • выделение ключевых атрибутов, характеризующих ту или иную бизнес-сущность

Сложные концептуальные модели, содержащие десятки бизнес-сущностей, разбиваются на домены. Домен – группировка «родственных» сущностей, образующих модель отдельного фрагмента моделируемой предметной области.

 

Логический уровень моделирования

Логическая модель является уточнением и детализацией концептуальной модели. Но это лишь с одной стороны.  На построение логической модели также влияет:

  • тип планируемой СУБД, которая будет воплощать модель
  • класс проектируемой системы: операционная (транзакционная) или аналитическая (BI)

Логический уровень моделирования – это уровень логики организации данных, то есть какие данные и как сгруппированы и связаны друг с другом. Концептуальный уровень больше заботится о смысловых связях, логический – о связях атрибутивных.  Концептуальный уровень оперирует бизнес-сущностями, логический – сущностями будущей информационной системы (например, базы данных).

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

Тип объектов логического уровня соответствует типам объектов избранной СУБД. Для реляционных и объектно-ориентированных баз данных – это ENTITY (сущность). Сущности логического уровня – это сущности, которыми оперирует информационная система (база данных или сервер приложений). К сущностям логического уровня подвязываются методы работы с этими сущностями.

Базовый элемент логической модели: сущность (иногда - данные).

Для проектирования реляционных баз данных используется нотация ERD. Рамками этой нотации фактически и задаётся логический уровень моделирования. Однако для систем, имеющих на верхнем уровне объектную модель, логический уровень описывается диаграммной классов. Детализирующие (вспомогательные) и часто используемые диаграммы логического уровня моделирования – это диаграммы состояний.

Примеры сущностей (классов):

  • клиент  -► party + customer + customer_profile + person
  • продукт  -► продукт + предложение продукта + price plan
  • заказ  -► order, order_item

Фокус моделирования: 

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

Немаловажное влияние на сущности логического уровня и их взаимосвязи оказывает тип проектируемой системы. Если проектируемая система относится к BI-классу, то следует понимать назначение BI-системы, ожидаемые от нее витрины, срезы, аналитики, метод моделирования времени (динамики изменения данных) и т.п.

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

Важное замечание. При разработке новой информационной системы, являющейся частью комплекса унаследованных систем, часто приходится использовать как проектирование сверху вниз (от концептуального уровня к физическому), так и обратное – снизу вверх: от уже существующих физических моделей к логической и далее мапирование в концептуальную. Это на порядок или даже на 2 порядка усложняет проектирование даже если нужно создать/автоматизировать один сквозной процесс, протекающий через ряд информационных систем.

Иногда при проработке логического уровня возникают сущности, которые трудно подвязать к бизнес-сущностям концептуального уровня и тогда возникает вопрос: нужно ли на концептуальном уровне завести новую бизнес-сущность? Ответ таков:

  • с одной  стороны, не стоит перегружать концептуальный уровень.
  • с другой стороны, если на концептуальном уровне появляется новая сущность, она должна быть отражена в глоссарии, как принципиально новое понятие, существенно отличное от других понятий данной предметной области.  

Каждый вендор информационной системы имеет логическую модель своей системы даже если он и не раскрывает ее своим клиентам. При интеграции нескольких систем приходится сначала увязывать их логические модели на концептуальном уровне моделирования, а лишь потом строить связи между логическими моделями разных систем. Например, в системе автоматизации продаж клиент может быть представлен как PARTY, в ERP-системе той же компании как КОНТРАГЕНТ, а системе биллинга той же компании, как АБОНЕНТ.

 

Физический уровень моделирования

Физический уровень – это уровень таблиц для реляционных моделей данных.

Базовый элемент физической модели: таблица.

Примеры таблиц:

  • клиент   -► table_1
  • продукт  -► table_2 
  • сделка -► table_3

Не исключается, что одна таблица физического уровня может участвовать в моделировании сразу нескольких физических сущностей.

Фокус моделирования

  • Выделение отдельных таблиц (в том числе как результат нормализации данных).
  • Выделение справочников.
  • Определение ключей.
  • Разделение атрибутов на простые атрибуты и перечисления (будущие справочники)

В простейших случаях логические объекты (сущности) совпадают с объектами физического  уровня. Это характерно для самых простых баз данных реляционного типа.