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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Шаг назад. Концептуальная модель может быть просто семантической сетью понятий бизнеса, то есть она может создаваться вне целей дальнейшей автоматизации. Как правило мы называем такую модель онтологией. Я бы рекомендовал начинать именно с этого.  Рассмотрим простейший пример. Перед нами текст, описывающий бизнес-ситуацию (ситуацию некого фрагмента реальности):

"клиент по имени Петров оплатил счет в размере 450 рублей и получил чек за три ручки и два карандаша марки "Архитектор" в торговой точке (канцелярский бутик) внутри магазина "ГУМ" (Москва); основанием для покупки явилось воздействие рекламной компании, проводимой по радио".

Что мы можем выделить из этого текста в качестве концептов (ключевых смыслов)? 

• Концепты: Клиент. Счет. Оплата. Покупка. Чек. Товар. Кампания. Точка продаж. Рекламный канал.
• Отношения концептов: Клиент совершает Покупку. Клиент совершает Оплату. Клиент получает Товар. Чек отражает Оплату. Оплата соответствует Счету. Покупка совершена в Точке продаж. На Покупку повлияла Кампания. Кампания проводилась в рекламном Канале. Кампания таргетировала определенный Тип Клиентов.

Всё, выделенное выше жирным, станет предметом рассмотрения и детальной проработки в логической модели. То есть фактически в нашем примере мы выделили те концепты и их отношения, которые будут зафиксированы в физической модели нашего будущего приложения.  Но такая концептуальная модель уже подогнана под автоматизацию (под идею будущей автоматизации), а значит она, возможно, упускает ряд существенных элементов, например, клиент имеет намерение совершить покупку. Или не имеет такого намерения и его надо "подогреть" в рекламной компании? Значит мы упустили намерение, как концепт. К какому типу принадлежит клиент, подверженный рекламе? - это сегмент рынка, на котором мы решили работать. Три ручки и два карандаша - это пишущие приборы. В чем состоит потребность их использования? Что мы знаем об этой потребности, как она (потребность, ценность) может быть зафиксирована в базе данных и нужно ли ее фиксировать? Что если клиент не оплатил счет, а лишь выписал счет (выписанный счет, оформленный, но не оплаченный заказ) и пошел думать на тему, где взять деньги (кредит) на покупку? Можем ли мы считать такого клиента покупателем или это lead, prospect (потенциальный клиент). Все эти концепты могут и должны быть предметом концептуального описания (концептуального моделирования), но возможно многим из них не суждено получить воплощения в будущей программной системе.

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

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

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

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

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

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

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

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

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

• клиент  -► party + customer
• контрагент  -► person, company
• customer_profile  -► клиенсткий профиль
• продукт  -► продукт + предложение продукта + price plan
• заказ  -► order
• элемент заказа  -► order_item
• лицевой счет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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