«Человек живёт только в настоящее мгновение. Всё остальное или прошло уже, или, неизвестно, будет ли.»
 
Консалтинговая компания Марк Аврелий


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

Известно и чаще всего встречается три вида моделей данных и соответсвенно три способа моделирования данных. Каждый способ моделирования отражает строго один опеределенный аспект данных, где аспекты (внимание!) - это темпоральные стадии процесса проектирования (процесс "от замысла до воплощения") некой системы, управляющей данными. Здесь данные - это [не строго] некоторый конгломерат информации об окружающем нас мире, имеющий ценность для пользователя/потребителя этой информации.

Каждый из способов моделирования порождает свою модель, где модель - это множество элементов, образующих слой данных определенного уровня абстрактности или детальности:

  • Концептуальный -► концептуальная модель. Цель модели - установить семантику (дать определение, установить смыслы) моделируемых явлений реальности и их информационные взаимосвязи.
  • Логический -► логическая модель. Цель модели  - логически выверенный, оптимизированный и нормализованный набор атрибутов, характеризующих данные, а также связанные с данными методы их обработки.  Логический уровень являет собой также спецификацию на реализацию данных в определенной  выбранной технологии. Более строго за логическом уровнем следует уровень спецификации и уровень конфигурации данных, о чем хорошо знают сторонники ООП.
  • Физический -► физическая модель. Программное воплощение структур данных.
  • Собственно данные - модель реальности, выраженная в символьно-числовом виде. То есть это уже не модель данных, а отражение реальности в конкретных экземлярах, внесенных в физическую модель.

Почему моделей (подходов к моделированию) и соответственно слоёв данных именно три? На этот вопрос можно ответить по разному:

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

Слоёв может быть и больше - смотри подробности и концепты, изложенные, например, в Zaсhman Framework. Есть весьма веские основания иметь более трех слоёв  -Identification, Concept, System/Logical, Specification, Configuration, Instantiation - со временем данная статься обогатится этими основаниями, но пока уясним суть ниболее часто востребованных моделей или порождаемых ими слоёв данных. Прим: слои Specification & Configuration нужны по той причине, что данные могут конструироваться  приложением динамически в ходе работы ПО, а не заранее, то есть статически.

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

В концептуальном слое моделирования (или на концептуальном уровне моделирования) мы определяем основные понятия предметной области и их взаимосвязь. Иногда также используют термин "построение онтологиии предметной области". В сущности - это семантическая модель предметной области или одного из её доменов.

Базовый элемент концептуальной модели: бизнес-сущность или бизнес-объект, или концепт. Что есть концепт? - что-то близкое к определению или дефиниции. То есть задача концептуальной модели дать границы (или окрестности) сущностей, то есть определить объем понятия, который стоит за неким словом (или более точно - обозначающим знаком).

Примеры концептов или бизнес-сущностей:

  • клиент (как вариант, клиент-ФЛ, клиент-ЮЛ) - это ....<далее идет попытка вербально определить основные характерстики, позволяющие отнести наблюдаемое явление к тому, что обозначается словом клиент>
  • продукт (как вариант, товар, услуга) - это < ... ... ... >
  • сделка (как вариант, заказ) - это < ... ... ... >
  • контракт - это < ... ... ... >.

Концептуальная модель в своём упрощенном виде, как правило,  представлена в документах класса ГЛОССАРИЙ (примечание: это может быть как местная wiki, так и разрозненные главы типа "Глоссарий"  в различных документах компании). Схематически (графически) наиболее удобным способом отображение концептуальной модели является диаграмма типа "диаграмма классов".  Связи между бизнес-сущностями (концептами) полезно «окрашивать»  действиями из предметной области, например, клиент заключает сделку, заказ состоит из товаров. Наилучшая нотация для концептуального уровня – подборка элементов из слоя Business и Motivation методологии Archimate. В данной нотации рекомендуется использоваться объект Meaning,  а также бизнес-сущности (Business Objects). Последние могут быть привязаны к ряду других архитектурных компонент (например, value или capability), что улучшает их окрашивание или лучше структурирует (делает более наглядной) моделируемую предметную область.

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

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

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

    В крупных проектах приходится поддерживать две концептуальных модели (модели двух видов):

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

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

    • при создании BI-систем
    • при создании модели данных интеграционной платформы.

    Поддержание концептуальной модели данных возможно в российском ПО класса Enterprise Architect - СиММА.



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

    Логическая модель является уточнением и детализацией концептуальной модели. Более точное выражение - это спецификация концептуальной модели. Но это лишь с одной стороны.  С другой стороны, на построение логической модели (на создание спецификации данных) также влияет:

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

    Логический уровень моделирования – это уровень логики организации данных, то есть какие данные и как сгруппированы и связаны друг с другом. Концептуальный уровень больше заботится о смысловых связях, логический – о реальных связях между объектами системы (ссылки объектов друг на друга, отношения объектов). Концептуальный уровень оперирует бизнес-сущностями, логический – сущностями будущей или фактически имеющейся информационной системы (например, базы данных). В компаниях с большой историей логический уровень задан фактически развернутыми системами конкретных вендоров. Слово "логический" стоит понимать в смысле "строго выверенный по правилам математической логики". Слово СПЕКА нужно держать в уме постоянно. Не бывает нестрогих спецификаций.

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

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

    Базовый элемент логической модели: КЛАСС (сущность в ООП) или собственно ENTITY (сущность, таблица для реляционных баз данных).

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

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

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

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

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

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

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

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

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

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

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

    О необходимости тщательного сопряжения логического и концептуального уровня много написано в DDD (Domain Driven Design). 

    И еще раз акцентируем внимание, что все чаще (да уже и практически всегда) объекты/классы проектируются как объекты поведения (при измельчении микросервисов), а не объекты группировки данных. Это сильно усложняет контроль за проектированием целостности и связности данных. Это просто усложняет проектирование, что и необходимо, и неизбежно.


    Поддержание логической модели данных возможно в российском ПО класса Enterprise Architect - СиММА.



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

    Физический слой – это слой таблиц для реляционных моделей данных. С точки зрения ИТ - это слой наивысшей детализации данных. Инвентаризация данных на этом уровне в корпоравтином масштабе крайне затруднительна: для одной-двух-двадцами систем это можно сделать вручную. Если систем десятки и сотни, то такую инвентаризацию нужно делать автоматически путем автомазированного сбора метаданных. Или отказаться от идеи инвентаризации физических структур данных в репозитории, ограничившись лишь ведением логической модели данных эксплуатируемых/развиваемых приложений. Физические модели в таком случае остаются описанными лишь в документации на системы и задача ведения репозитория - задача ведения реестра системной документации.

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

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

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

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

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

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

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

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


    Еще один вариант данной статьи смотри на сайте "Марка Аврелия" - о трех уровнях моделирования данных. Обе статьи одинаково полезны, так как затрагивают различные нюансы в моделировании данных.