Когда нужен Логическая модель данных

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

Когда Логическая модель данных не нужен

Когда нужно описать физическую реализацию в конкретной СУБД — берите физическую модель Если требуется только перечень бизнес-понятий без структуры связей — берите концептуальную модель При описании конкретных программных продуктов или версий — берите модель реализации

Типичные ошибки: Логическая модель данных

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

Логическая модель данных Logical Data Model

На какой вопрос отвечает «Как связаны информационные объекты предприятия независимо от систем хранения?»

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

Аналогия Это как план этажа здания, где отмечены комнаты и их назначение, но нет чертежей проводки и труб.

Разобраться

Зачем это нужно

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

Применить

Когда это нужно, а когда нет

Когда нужно

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

Когда не нужно

Когда нужно описать физическую реализацию в конкретной СУБД — берите физическую модель
Если требуется только перечень бизнес-понятий без структуры связей — берите концептуальную модель
При описании конкретных программных продуктов или версий — берите модель реализации

Типичные ошибки

01Подмена логической модели физическим описанием таблиц и полей конкретной базы данных.
02Игнорирование различия между уровнем типов и уровнем экземпляров при описании сущностей.
03Создание модели без привязки к бизнес-задачам, что приводит к набору бессмысленных абстракций.

Сверить с первоисточниками

Что говорят стандарты

Определения из источников с переводом и ссылкой на раздел. Категория показывает назначение каждого подхода.

The DIV-2 allows analysis of an architecture's data definition aspect, without consideration of implementation specific or product specific issues. Another purpose is to provide a common dictionary of data definitions to consistently express models wherever logical-level data elements are included in the descriptions. Data definitions in other models include:

Раздел стандарта

The OV-7 addresses the information modelling perspective of an operational architecture.

Перевод Структура информации операционного уровня: информационные сущности и их отношения.

Раздел стандарта

Presents data requirements that reify the information concepts identified by corresponding Conceptual Information models

Перевод Представляет требования к данным, овеществляющие информационные концепты, выявленные в соответствующих концептуальных информационных моделях.

Раздел стандарта

The base model distinguishes between entities, attributes, and relationships. Basically, a distinction is made between type level and occurrence level. Entities are real or abstract objects that are relevant for the business management tasks being examined.

Перевод Базовая модель данных: сущности, атрибуты и связи, с различением уровня типов и уровня экземпляров. Сущности — реальные или абстрактные объекты, значимые для предприятия.

Раздел стандарта

Ещё 1 редакция этого подхода

The IE data model complies with the data modeling notation of the Information Engineering Facility (IEF) CASE tool by Texas Instruments Inc. It does not provide proprietary object types for relationships between entity types. The following figure illustrates an example of a data model in IE notation.

Перевод Модель данных в нотации Information Engineering как альтернатива eERM.

Логическая модель данных (каталог логических объектов данных).

Перевод Каталог логических объектов данных — средний уровень детальности метаданных.

Раздел стандарта

С чем связано

Связи понятия и его место в структуре подхода.

Data and Information Viewpoint (DIV) — данные и информация

Operational Views (OV) — логическая (не физическая) операционная деятельность

Data — данные и информация (референсная модель DRM)

Data view / Requirements definition

Домен №3. Данные

Эквиваленты по категориям

Logical Data ModelИнформация и данные

Логическая структура данных без привязки к СУБД.

Семантические различия MODAF называет это OV-7 Information Model и относит к операционному ряду, DoDAF — к ряду данных: одно содержание, разное место в сетке. ARIS даёт две нотации (eERM и IE).