Когда нужен Физический компонент данных

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

Когда Физический компонент данных не нужен

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

Типичные ошибки: Физический компонент данных

Смешение логической модели данных с физическим представлением в конкретной СУБД или файловой системе. Игнорирование формата или схемы, требуемого технологией, при описании компонента. Неправильное определение границ компонента, когда в него включают несвязанные сущности.

Физический компонент данных Physical Data Component

На какой вопрос отвечает «В каком виде и где физически хранятся данные для данной технологии?»

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

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

Разобраться

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

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

Применить

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

Когда нужно

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

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

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

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

01Смешение логической модели данных с физическим представлением в конкретной СУБД или файловой системе.
02Игнорирование формата или схемы, требуемого технологией, при описании компонента.
03Неправильное определение границ компонента, когда в него включают несвязанные сущности.

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

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

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

A data structure that realizes related logical data components represented in the format or schema required by a particular technology.

Раздел стандарта Строка реестра

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

A boundary zone that encapsulates related data entities to form a physical location to be held. For example, a purchase order business object, comprising purchase order header and item business object nodes.

Перевод Архитектурная сущность TOGAF: физический компонент данных.

TOGAF Standard, Version 9.2, The Open Group, 2018, C182; гл. 30 «Content Metamodel», §30.5 «Content Metamodel Entities», табл. «Metamodel Entity | Description»

С чем связано

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

Architecture Definition: Information Systems Architecture — Data / Определение архитектуры: архитектура информационных систем — данные

РеализуетсяLogical Data Component
ИспользуетсяPhysical Application Component
РеализуетLogical Data Component
ИспользуетсяPhysical Application Component
Декомпозируется наPhysical Data Component

Связанные понятия

Понятия, которые обычно смотрят рядом с этим.

Технологический компонент Технологический сервис Требование Физический компонент приложения Физический технологический компонент Функция Актор Компонент приложения Прикладной сервис Архитектурные строительные блоки Принципы архитектуры

14 дней бесплатно

Опишите архитектуру своей компании в Storm

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

Попробовать бесплатно Без банковской карты

Это же в StormАрхитектура систем и интеграций Граф связей реестра Реестр процессов