Концептуальное логическое и физическое моделирование данных
Известно и чаще всего встречается три вида моделей данных и соответсвенно три способа моделирования данных. Каждый способ моделирования отражает строго один опеределенный аспект данных, где аспекты (внимание!) - это темпоральные стадии процесса проектирования (процесс "от замысла до воплощения") некой системы, управляющей данными. Здесь данные - это [не строго] некоторый конгломерат информации об окружающем нас мире, имеющий ценность для пользователя/потребителя этой информации.
Каждый из способов моделирования порождает свою модель, где модель - это множество элементов, образующих слой данных определенного уровня абстрактности или детальности:
- Концептуальный -► концептуальная модель. Цель модели - установить семантику (дать определение, установить смыслы) моделируемых явлений реальности и их информационные взаимосвязи.
- Логический -► логическая модель. Цель модели - логически выверенный, оптимизированный и нормализованный набор атрибутов, характеризующих данные, а также связанные с данными методы их обработки. Логический уровень являет собой также спецификацию на реализацию данных в определенной выбранной технологии. Более строго за логическом уровнем следует уровень спецификации и уровень конфигурации данных, о чем хорошо знают сторонники ООП.
- Физический -► физическая модель. Программное воплощение структур данных.
- Собственно данные - модель реальности, выраженная в символьно-числовом виде. То есть это уже не модель данных, а отражение реальности в конкретных экземлярах, внесенных в физическую модель.
Почему моделей (подходов к моделированию) и соответственно слоёв данных именно три? На этот вопрос можно ответить по разному:
- три слоя - это три уровня абстракции. Такой ответ подчеркивает нисходящий подход от общего к частному, от контуров замысла о данных к их физическому воплощению. Недостаток такого взглядя заключается в том, что между уровнями абстракции многие затрудняются установить строгие отношения конгруэнции трех множеств. Она (конгруэнция) отнюдь не простая, но весьма строгая и отражает именно нисходящий поток проектирования.
- три слоя - это темпоральные стадии одной и той же атомарной единицы - единицы данных. В таком случае концептуальный уровень задаёт смысловой объем понятия, заключенного в единице данных, логический - описывает спецификацию единицы данных, физический - описывает реализацию единицы данных.
Слоёв может быть и больше - смотри подробности и концепты, изложенные, например, в 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
Не исключается, что одна таблица физического уровня может участвовать в моделировании сразу нескольких логических сущностей.
Фокус моделирования:
- Выделение отдельных таблиц, в том числе как результат нормализации данных.
- Выделение таблиц-справочников.
- Определение ключей.
- Разделение атрибутов на простые атрибуты и перечисления (будущие справочники).
В простейших случаях логические объекты (сущности) совпадают с объектами физического уровня. Это характерно для самых простых баз данных реляционного типа.
В потоковых системах, где структурирование данных не выполняется в момент их порождения и накопления, данные на физическом уровне могут представлять просто тексты и строки. Преобразование таких данных к интерпретируемому виду будет выполняться по требованию согласно схеме, определенной в логическом слое, который в этом случае можно считать слоем интерперетации сырых данных.
Еще один вариант данной статьи смотри на сайте "Марка Аврелия" - о трех уровнях моделирования данных. Обе статьи одинаково полезны, так как затрагивают различные нюансы в моделировании данных.