От объекта к системе

Глава 12. Связь как самостоятельный объект

12.1. Болт, который входит в три узла

Представим простой крепёжный элемент. Болт М8×20. Он используется в трёх разных узлах одного изделия: в креплении двигателя, в креплении корпуса, в креплении защитной крышки.

Сам болт один. Но связей три. И каждая связь имеет собственные свойства.

В креплении двигателя болт стоит в позиции 10, в количестве четырёх штук. В креплении корпуса — в позиции 25, в количестве восьми штук. В креплении крышки — в позиции 42, в количестве двух штук.

Позиция, количество, роль, контекст применения — всё это свойства не болта. Но и не свойства двигателя, корпуса или крышки. Они принадлежат отношению между объектами.

Если модель данных хранит только объекты:

Болт
Двигатель
Корпус
Крышка

она знает, что эти объекты существуют. Но она не знает, как они связаны. Она не знает, что болт входит в двигатель в позиции 10. Не знает, что в корпусе требуется восемь штук. Не знает, что в крышке он применяется только для определённого исполнения.

Эта информация не принадлежит ни одному из объектов. Она принадлежит связи.

И если связь не является самостоятельной частью модели, эта информация либо оказывается искусственно «приклеенной» к одному из объектов, либо теряется.

12.2. Человек мыслит отношениями

Когда инженер смотрит на автомобиль, он не видит просто перечень деталей. Он видит структуру.

Двигатель соединён с коробкой передач. Коробка передач соединена с карданным валом. Карданный вал соединён с задним мостом. Подвеска связывает кузов с колёсами. Электрооборудование связывает аккумулятор с потребителями.

Инженер постоянно задаёт вопросы, относящиеся именно к отношениям:

• какой компонент установлен в этом узле;
• в каком количестве;
• в какой позиции;
• какую функцию он выполняет;
• для какого исполнения он применяется;
• с какого момента применяется;
• каким документом или решением установлена эта связь.

Ни на один из этих вопросов нельзя ответить, рассматривая только сами объекты.

Значит, связь является частью инженерного знания.

12.3. Ссылка и связь — не одно и то же

В обычной реляционной модели связь часто представляется внешним ключом:

assembly
    component_id → component

Технически этого достаточно, чтобы сказать: этот компонент связан с этим узлом. Но для инженерной системы этого недостаточно.

Нужно знать:

Assembly
    |
    └── Relation
            component: Bolt M8×20
            position: 10
            quantity: 4
            role: fastening
            applicability: ...
            valid_from: ...

Внешний ключ отвечает на вопрос: с чем связан объект?

Инженерная связь отвечает на более важный вопрос: что означает эта связь?

Это принципиальная разница. Ссылка является техническим механизмом соединения записей. Связь является частью предметной модели.

12.4. Когда связь становится самостоятельным объектом

Не всякая ссылка между объектами должна становиться отдельным объектом.

Если документ имеет автора, обычно достаточно сохранить ссылку:

Document
    author_id

Автор является свойством документа. Само отношение «документ написан автором» не требует отдельной инженерной сущности. Но ситуация меняется, когда отношение обладает собственной информацией и собственной жизнью.

Критерий прост. Связь является самостоятельным объектом, если:

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

Связь «изделие содержит компонент» удовлетворяет этим критериям. Она может иметь:

• позицию;
• количество;
• условие применения.

При этом изменение количества болтов с четырёх до шести не изменяет сам болт и не изменяет сам узел. Изменяется отношение между ними. Следовательно, отношение должно быть самостоятельной сущностью модели.

Здесь возникает важное практическое правило:

если свойства самой связи имеют инженерный смысл, они не должны быть спрятаны в одном из связанных объектов.

Если позиция, количество и условия применения находятся внутри Component, они теряют связь с конкретным узлом. Если они находятся внутри Assembly, они теряют связь с конкретным компонентом. Они должны существовать там, где им принадлежит — в самой связи.

12.5. KRelation

В модели Constructum эта идея выражается через самостоятельную сущность модели — KRelation, представляющую связь между объектами.

Упрощённо:

KObject A
    |
    └── KRelation
            |
            └── KObject B

KRelation не заменяет связанные объекты. Он не является ни первым объектом, ни вторым. Он представляет сам факт и смысл их отношения.

Например:

KProduct: Насос Н1
        |
        └── KRelation
                type: contains
                target: KProduct — Уплотнение У1
                quantity: 2
                position: 15
                applicability: ...

Насос существует самостоятельно. Уплотнение существует самостоятельно.

Связь между ними также существует самостоятельно.

Это позволяет модели хранить не только набор объектов, но и структуру изделия.

12.6. Почему связь должна иметь собственную идентичность

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

Если есть:

A → B

зачем ещё один объект?

Ответ появляется, когда связь начинает изменяться. Сегодня:

A
 └── contains → B
                quantity: 4

Завтра:

A
 └── contains → B
                quantity: 6

Что изменилось?

Не A.

Не B.

Изменилось отношение между A и B.

Если отношение не имеет собственной сущности, системе приходится искусственно привязывать историю изменения либо к A, либо к B. Но это неверно. Изменение принадлежит связи.

Поэтому у связи должен быть собственный жизненный цикл.

Она может появиться. Может измениться. Может быть закрыта. Может быть заменена другой связью.

И при этом связанные объекты продолжают существовать.

12.7. Связь может быть объектом изменения

Рассмотрим изменение конструкции.

В исходной структуре:

Насос Н1
    └── contains → Уплотнение У1
                     quantity: 2

После изменения:

Насос Н1
    └── contains → Уплотнение У1
                     quantity: 4

Сам насос не изменился как объект. Само уплотнение не изменилось как объект.

Изменилось количество применяемых уплотнений. Это изменение отношения.

А значит, если система должна хранить историю инженерных решений, она должна уметь версионировать или темпорально хранить именно отношение. Это особенно важно для BOM (почему используется термин “BOM” смотри главу 12б).

BOM — это не просто список объектов. BOM — это структура отношений между объектами.

Именно поэтому изменение BOM не всегда означает изменение самих объектов, входящих в неё.

12.8. Связь может иметь собственный контекст

Рассмотрим тот же болт.

Он может применяться:

Узел A
    quantity = 4

Узел B
    quantity = 8

Узел C
    quantity = 2

Кроме количества могут отличаться:

• позиция;
• условия использования.

Это означает, что одна и та же пара объектов потенциально может иметь разные отношения в разных условиях. Связь поэтому не является просто парой идентификаторов.

Она является самостоятельным носителем инженерной информации.

12.9. Связь между Definition и объектом

Тот же принцип работает не только для структуры изделия.

Описание объекта также связано с объектом отношением.

Например:

KProduct
    |
    └── KDefinition
            |
            └── Revision

Здесь важно различать сами сущности.

KProduct — объект. KDefinition — описание этого объекта. Revision — версия описания.

Это не три записи об одном и том же. Это разные сущности, существующие для разных целей. Так же и Relation не является «полем объекта». Он представляет самостоятельное отношение между объектами.

12.10. Связь между экземпляром и применённым описанием

То же различие необходимо при работе с изготовленными экземплярами.

Изготовленный экземпляр является самостоятельным объектом. Он не является просто строкой в таблице изделия. Он имеет собственную историю, собственный учёт и собственное состояние.

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

Например:

KProduct
    └── KDefinition
            ├── Revision A
            ├── Revision B
            └── Revision C

KInstance №003
    applied_revision: Revision B

Здесь Revision не превращается в экземпляр и не становится частью объекта Product. Revision остаётся версией описания. KInstance остаётся самостоятельным объектом.

Информация о применённой версии относится к экземпляру и позволяет восстановить состояние, в котором конкретный экземпляр был изготовлен.

Это принципиально важно для прослеживаемости.

12.11. Связь как часть истории изделия

Представим, что через десять лет необходимо выяснить: Какие изделия содержали данный компонент на момент выпуска?

Если система хранит только текущую структуру:

A → B

она знает только сегодняшнее состояние.

Но инженерный вопрос относится к прошлому.

Нужно знать:

2026:
    A → B
2028:
    A → C
2030:
    A → D

История относится не только к объектам. Она относится к отношениям между объектами. Поэтому изменение структуры изделия невозможно корректно представить, если система умеет хранить только текущие ссылки.

12.12. Отношения образуют граф

Из этого возникает важное следствие.

Изделие в цифровой системе — это не таблица деталей. Это граф объектов и отношений.

             KProduct
                │
          ┌─────┴─────┐
          │           │
      KRelation    KRelation
          │           │
       Component    Component
          │
      KRelation
          │
       Document

Каждый узел графа является самостоятельным объектом. Каждое значимое отношение между узлами также является самостоятельной сущностью.

Поэтому система хранит не просто набор записей. Она хранит структуру инженерного мира.

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

Эта идея не является особенностью модели Constructum. Она имеет прямое подтверждение в международных стандартах.

ISO 10303-239 (PLCS) вводит отдельную сущность product_definition_relationship. Она предназначена для представления отношения между двумя определениями изделия и содержит собственную семантику отношения. Стандарт не сводит отношение к технической ссылке между двумя записями.

NPDM (NATO Product Data Model, STANAG 4613) также разделяет объекты и отношения между ними. Модель использует отдельное представление отношений между компонентами продукта. Для таких отношений могут существовать собственные характеристики: количество, позиция, условия применения.

ANSI/EIA-649-D требует идентифицировать не только сами configuration items, но и отношения между ними. Конфигурация определяется не только набором объектов, но и тем, как эти объекты связаны.

Отечественная система ЕСКД выражает тот же принцип через спецификацию (ГОСТ 2.106-2019) и электронную структуру изделия (ГОСТ Р 2.053-2023). Спецификация не является простым перечнем деталей. Она фиксирует состав, позиции и количество — то есть отношения между изделием и его компонентами.

Во всех случаях отношение является частью модели, а не технической ссылкой.

12.14. Граница: не всякое отношение является инженерной сущностью

Здесь важно не превратить принцип в догму.

Самостоятельность связи — это прежде всего семантическое требование. Не каждая техническая ссылка в базе данных обязана становиться отдельным KRelation. Если отношение не имеет собственного смысла, свойств и жизненного цикла, обычной ссылки достаточно.

Например:

KDocument
    created_by = User

Нет необходимости создавать отдельный объект только ради того, чтобы представить автора документа.

Но:

KAssembly
    contains
        component
        position
        quantity
        applicability
        validity

уже представляет инженерное отношение. Здесь отдельная сущность оправдана содержанием, а не технологией хранения.

Граница проходит по смыслу.

Если отношение является лишь способом указать владельца, автора или иной простой признак, достаточно ссылки.

Если отношение несёт самостоятельную инженерную информацию, изменяется независимо, имеет историю или определяет структуру изделия, оно должно быть представлено как самостоятельная сущность.

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

12.15. Связь с предыдущими главами

Глава 10 установила: документ не является объектом. Объект существует независимо от документа.

Глава 11 установила: объект сохраняет свою идентичность, а его описание изменяется во времени.

Глава 12 добавляет: отношения между объектами могут быть самостоятельными сущностями. Модель данных должна хранить не только объекты, но и смысл их связей.

Вместе эти главы формируют следующую картину:

Что существует?
        ↓
      Object

Как объект описан?
        ↓
    Definition

Как описание изменяется?
        ↓
     Revision

Как объекты связаны?
        ↓
     Relation

Это четыре разных уровня модели.

Объект отвечает на вопрос что существует. Описание отвечает на вопрос что мы знаем об этом объекте. Revision отвечает на вопрос какая версия этого описания действовала. Relation отвечает на вопрос как этот объект связан с другими объектами.

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

12.16. Главный вывод

Объекты сами по себе не описывают инженерный мир.

Между ними существуют отношения. И эти отношения часто содержат не меньше инженерной информации, чем сами объекты.

Болт не просто связан с узлом. Он входит в него в определённой позиции, в определённом количестве и при определённых условиях. Компонент не просто связан со сборкой. Он входит в определённую структуру. Документ не просто связан с изделием. Он описывает определённый объект. Изготовленный экземпляр не просто связан с описанием. Он содержит информацию о том, какая версия описания была применена при его изготовлении.

Поэтому модель данных должна уметь хранить не только объекты, но и смысл отношений между ними.

В Constructum для этого используется KRelation. KRelation не заменяет связанные объекты. Он представляет саму связь между ними как самостоятельную сущность, если эта связь имеет собственный инженерный смысл, свойства или жизненный цикл.

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

Если система хранит только объекты, она знает, что существует. Если она хранит объекты и отношения, она знает, как устроен инженерный мир.

Часть II завершена. Мы установили, что документ не является объектом, что объект сохраняет свою идентичность при изменении описания и что значимые отношения между объектами являются самостоятельными сущностями модели. В Части III мы перейдём от модели данных к архитектуре системы: как эта модель определяет границы сервисов, правила изменений и поведение платформы.

Примечания к главе 12

Источники:

• ISO 10303-239, Industrial automation systems and integration — Product data representation and exchange — Part 239: Application protocol: Product life cycle support.
• NATO CALS Office, NPDM Version 4.10 — NATO Product Data Model, STANAG 4613 / ALP-14.
• ANSI/EIA-649-D, Configuration Management Standard, SAE International, 2019. §3.3.
• ГОСТ Р 2.053-2023. Единая система конструкторской документации. Электронная структура изделия. Общие положения.
• ГОСТ 2.102-68. Единая система конструкторской документации. Виды и комплектность конструкторских документов.
• ГОСТ Р 2.101-2023. Единая система конструкторской документации. Виды изделий.
• ГОСТ Р 2.005-2023. Единая система конструкторской документации. Термины и определения.
• Rönnbäck, L. et al. Anchor Modeling: An Agile Modeling Technique Using the Sixth Normal Form. 2010.

Типы доказательств: