D06 — Модель данных (платформонезависимая)¶

Домен: D06 — УМД и контент · Статус: draft (черновик для ревью). Что моделируем: норма-ось академического контура — образовательную программу как комплект-манифест и её компоненты. «Кого/сколько учим» (Набор, контингент) — это D05; «что произошло» (ведомости, обязательства) — D04. Здесь только «чему и как». Версионность: норма версионируется только вперёд и только по изменению (не по календарю). Год набора — это привязка когорты к версии (живёт в D05), а не сама версия. Нормативка: ссылки на ФЗ-273 даны для ориентира и подлежат сверке человеком (см. CLAUDE.md).

1. Сущности¶

1.1 ОПОП (манифест)¶

Образовательная программа как корень-комплект: собственного содержания почти не несёт, задаёт идентичность и держит ссылки на версии компонентов (ФЗ-273 ст. 2 — «комплекс, представленный в виде учебного плана, …»). Применимость: [ВУЗ, СПО].

Вариант для ДПО. Дополнительная профессиональная программа (ДПП) — сестринская сущность того же типа, но норма-основание у неё не ФГОС, а профстандарт/квалтребования (ст. 76; для профпереподготовки с 01.03.2026 — также условия и результаты ФГОС СПО/ВО). Применимость [ДПО]. Моделируется отдельной карточкой на следующем шаге.

1.2 Версия ОПОП¶

Сам манифест: неизменный после утверждения снимок ссылок на версии компонентов. Новая версия рождается изменением любого компонента.

1.3 Учебный план¶

Структурный компонент: перечень, трудоёмкость, последовательность, периоды, формы промежуточной аттестации (ст. 2).

1.4 Строка учебного плана¶

Дискретная единица плана — конкретная дисциплина/модуль/практика в конкретном периоде.

1.5 Дисциплина / модуль / практика¶

Каталожная единица содержания. Переиспользуется строками планов.

1.6 Рабочая программа дисциплины (РПД)¶

Содержательный компонент нормы: как именно реализуется одна строка учебного плана — цель, результаты освоения, тематический план, условия реализации. Входит в состав версии ОПОП наравне с учебным планом и ФОС (ФЗ-273 ст. 2 — образовательная программа представлена в том числе «рабочими программами … дисциплин (модулей)»; ⚠ подлежит сверке человеком). Применимость: [ВУЗ, СПО, ДПО, Асп], ДО — partial.

Собственной оси версий не имеет. «Версия РПД» — это участие конкретной её редакции в Версия ОПОП.sostav; норма версионируется только вперёд и только по изменению (см. 1.2). Год набора в РПД не хранится — это привязка когорты к версии и живёт в D05.

Ключевой инвариант источника истины. РПД не владеет трудоёмкостью и формами контроля — она их проецирует из «Строки учебного плана» (read-only, пересобирается при смене версии плана). Норма-основание содержания — ФГОС; для ДПП — профстандарт/квалтребования.

Производные поля (read-only, проекция из учебного плана / справочников):

Разделы содержания (норма-структура; детальный реестр реквизитов — в машиночитаемом представлении, не дублируется здесь):

Жизненный цикл. draft → согласование → утверждение → (изменение любого реквизита → новая редакция → новая Версия ОПОП). Архивация — вместе с закрытием версии ОПОП для набора.

Инварианты. - Одна РПД ↔ одна строка учебного плана внутри версии плана (1:1). - derived-поля в РПД не редактируются: правка часов / форм контроля — только через учебный план, иначе два источника истины. - Компетенции не вводятся вручную, а ссылаются на узлы ФГОС (standards/fgos) через дескриптор результата освоения (§1.10). - РПД не хранит год набора и собственный номер версии (год — D05, версия — Версия ОПОП).

Вариант СПО. Вместо дисциплины — профессиональный модуль / МДК; добавляются комплексные формы контроля (квалификационный экзамен). Профиль — SPO.

Вариант ДПО (ДПП). Норма-основание — не ФГОС, а профстандарт/квалтребования (⚠ ст. 76; для профпереподготовки с 01.03.2026 — также условия и результаты ФГОС СПО/ВО). Появляются поля ЭО и ДОТ. Профиль — DPO.

Машиночитаемое представление. РПД формализована как JSON-Двойник — единый объект, обслуживающий заполнение, проверку, печать, обратное восстановление и трассировку:

• standards/rpd/schema/discipline-program-twin.schema.json — контракт (JSON Schema 2020-12), валидируется в CI наравне с standards/fgos;
• standards/rpd/data/discipline-program-twin.full-template.json — эталонный шаблон v0.2.0 (91 реквизит, профили по уровням, привязки печати, правила валидации);
• блоки forms / print / reverseImport Двойника — слой реализации: в стандарте описываются ссылкой, конкретные привязки живут в реализации (1С / веб), а не в норме.

Связи. derivedFrom → ФГОС (standards/fgos); partOf → Версия ОПОП; references → Строка учебного плана; evidences ← ФОС / оценочные материалы.

Формат адресации — JSON Pointer (RFC 6901), не собственная нотация. Поля fieldSource.sourcePath (внутри одного документа) и relationLink.from/.to (между документами, включая внешние — standards/fgos/data/*.json) объявлены в схеме с format: json-pointer / format: uri-reference. Решение принято по итогам разбора inbox/2026-07-06-univercon-fgos-rp-konspekt.md («Вопрос 1», common-ярус): вместо изобретения собственного языка связей — принят существующий IETF-стандарт (JSON Pointer) для адресации и паттерн JSON Reference (file.json#/pointer) для межфайловых ссылок. ⚠ Формат объявлен как целевой; 91 существующее значение sourcePath в эталонном шаблоне пока в dot-notation (curriculum.discipline.name), не мигрировано — см. открытый вопрос в CHANGELOG.

1.7 Фонд оценочных средств (ФОС)¶

Версионируемый компонент: чем измеряется достижение индикаторов.

1.8 Компетенция¶

Компетенция существует двумя разными способами в зависимости от типа — это не одна сущность с общим хранением, а два разных механизма под одним именем.

УК / ОПК — не хранятся в D06. Компетенция целиком живёт внутри документа ФГОС (standards/fgos/data/*.json, вложенные массивы competencies.universal[] / competencies.general_professional[]). D06 её не копирует к себе, а адресует напрямую естественной двойкой (fgos_id, kod). Проверено на реальных данных: поле indicators внутри компетенции ФГОС всегда пусто — стандарт задаёт только компетенцию, индикатор не входит в состав документа (см. §1.9).

ПК — хранимая D06-сущность. Устанавливается ОО на основе профстандарта; существует только в контексте конкретной версии ОПОП (разные версии ОПОП по одному направлению могут устанавливать разные ПК).

Естественный ключ ПК — (versiya_opop_id, kod), не синтетический UUID: ПК не существует вне контекста своей версии ОПОП, отдельный глобальный идентификатор не нужен.

1.9 Индикатор достижения компетенции¶

Всегда хранимая D06-сущность, независимо от типа компетенции (УК/ОПК/ПК). Проверено на реальных данных ФГОС: индикаторы там не заполняются — это исключительно авторская работа ОО, привязанная к версии ОПОП (см. §1.8).

Естественный ключ индикатора — (versiya_opop_id, kod). Индикатор физически живёт в версии ОПОП, не внутри документа нормы — синтетический UUID не нужен.

proishozhdenie — дискриминированная ссылка, не часть первичного ключа. Разводит «где хранится» (версия ОПОП, всегда) от «на основании чего сформулировано» (документ-источник или локальная ПК):

Инвариант: proishozhdenie не участвует в идентичности индикатора — два индикатора с одинаковым происхождением, но в разных версиях ОПОП, это разные строки (разный автор, возможно разная формулировка). Происхождение — атрибут, не ключ.

1.10 Дескриптор результата освоения (РПД)¶

Хранимая сущность внутри РПД (§1.6, раздел содержания «Результаты освоения»): конкретное обещание дисциплины по конкретному пункту нормы — «эта РПД формирует именно это знание/умение/навык ради именно этого индикатора». Автор — разработчик РПД; заполняется вручную, не выводится автоматически.

Дескриптор — хаб, норма не адресуется напрямую. Карточка занятия («формируемые компетенции», §1.12) и ФОС/оценочные средства (§1.7) ссылаются на дескриптор РПД, а не на индикатор нормы напрямую. Одна точка входа вместо нескольких при перевыпуске нормы (новая редакция ФГОС не требует правки ссылок во всех местах, где компетенция упоминалась, — только пересвязки дескриптора).

Матрица компетенций — вычисляемый вид, не хранилище. Сводная таблица «строка учебного плана × компетенция» собирается агрегацией дескрипторов всех РПД версии ОПОП: rpd_id → stroka_up_id (строка плана) и indikator_id → proishozhdenie (какая компетенция — либо (fgos_id, kod) из ФГОС напрямую, либо локальная ПК по kod_pk внутри той же версии ОПОП). Не хранится отдельной M:N-таблицей. Дублирующего источника истины не возникает: правда лежит в дескрипторах и индикаторах, матрица — их проекция для чтения (аккредитация, полнота покрытия).

1.11 Форма контроля (как норма)¶

Форма контроля — элемент нормы (описание того, что должно быть проверено). Это НЕ экземпляр проверки (последний живёт в D04 как факт: конкретная попытка на конкретном событии). Одна норма — много фактов.

Атрибуты (наследуются из academic-concept v1.4 §3.2, форма контроля как единая сущность с осями):

Три оси форм контроля (из Дидактикон Блок III):

1.12 Запланированное учебное событие¶

Родовое понятие: генератор обязательств в академическом контуре, зафиксированный на уровне плана (не в момент проведения). Термин совпадает с academic-concept v1.4 §4. Виды: занятие / модульный контроль / экзамен / зачёт / курсовая / день практики / ГИА.

Ключевой принцип (из доклада §4): «Расписание не создаёт события — оно их разворачивает». Событие возникает в плане (в РПД или УП), расписание (D14) его переносит в календарь и ресурсы, реализация (D04) фиксирует факт.

Инвариант: одно занятие в расписании (слот D14) может содержать 1..N запланированных учебных событий с разными правилами формирования состава (пример: само занятие + модульный контроль, где второй — не для всех).

Как формируется состав события: пересечение (кто имеет событие в траектории D05) × (кто активен на дату). Формулировка из §4 доклада: «состав каждого учебного события формируется в момент его наступления, из тех, у кого это событие стоит в траектории и чей статус позволяет на нём быть». Черновой состав вычисляется на старте, факт затвердевает через буфер (D04).

1.13 Пакет занятия¶

Пакет — манифест события, «картридж» (аналогия из §7 доклада): знает о дисциплине, теме, виде, форме контроля; не знает группу, дату, преподавателя. Один пакет — много запусков на разных группах, в разных семестрах, у разных преподавателей.

Модель наследует ключевые решения из lesson-package-concept.md (в inbox):

Инварианты пакета:

1. Стейтлесс. Пакет ничего не помнит между запусками. Прогресс, оценки, факты — в D04.
2. Атомарен. Один пакет = одна единица учебного процесса (одно занятие / один экзамен / один день практики).
3. Переиспользуем. Пакет применяется на многих запусках, пока РПД актуальна.
4. Три источника данных (base + overlay + runtime): база собирается из ИС, overlay — правки педагога, runtime — контекст запуска (группа, дата, преподаватель) подставляется в момент проведения.

1.14 Gate¶

Первоклассная сущность: шлюз, блокирующий проход по занятию до выполнения условия. Тексты gate — из централизованной библиотеки (вуз/кафедра), ad-hoc — исключение. Версионирование обязательно: факт прохождения привязан к версии текста.

Инвариант: пакет стейтлесс. Факт прохождения gate хранится в D04, а не в пакете. При запуске пакет спрашивает D04: «эти gate уже пройдены этим студентом?».

2. Жизненные циклы¶

2.1 Версия ОПОП (только вперёд)¶

изменение компонента → новая Версия ОПОП → утверждение → действует

• Нет изменений компонентов — новой версии нет; несколько наборов делят одну версию.
• После утверждения версия неизменна; правка = следующая версия.
• Ежегодное переутверждение без изменений — новое utverzhdenie_id, та же логическая версия.

2.2 Статусы ОПОП¶

draft → действует → закрыта-для-набора

«Закрыта-для-набора» не отменяет версию: пристёгнутые когорты доучиваются по своей.

3. Инварианты¶

1. ОПОП существует только в границах лицензии (D02): специальность × форма × адрес.
2. УК и ОПК импортированы из ФГОС и локально неизменяемы; ПК устанавливает ОО на основе профстандарта.
3. Версия ОПОП неизменна после утверждения; изменение компонента → новая версия (только вперёд).
4. Объём учебного плана равен объёму ФГОС с учётом долей обязательной и формируемой частей.
5. Каждая компетенция покрыта хотя бы одним дескриптором результата освоения (§1.10) в составе РПД версии ОПОП; матрица покрытия — вычисляемый вид над дескрипторами, не отдельное хранилище (полнота покрытия).
6. Каждый индикатор обеспечен хотя бы одним оценочным средством в ФОС.
7. ОПОП-манифест не содержит собственного учебного текста — только ссылки на версии компонентов.
8. Набор (D05) пристёгнут ровно к одной Версии ОПОП.
9. План учебных событий формируется в двух местах: в РПД (внутри дисциплины) и в строках УП (уровня программы). Единый план из двух уровней.
10. Форма контроля — норма, не факт. Одна форма контроля D06 порождает множество попыток проверки — но каждая попытка живёт в D04 как отдельная запись. Правка факта — только через сторно (D04), но не через изменение формы контроля.
11. Пакет — стейтлесс. Пакет знает о норме (дисциплина / тема / форма контроля / материалы / gates), но НЕ знает о runtime-контексте (группа / дата / преподаватель). Все факты запуска — в D04.
12. Расписание не создаёт события. События появляются в плане (РПД / УП); D14 только назначает им время, аудиторию, преподавателя. Один слот D14 может покрывать 1..N запланированных событий D06.
13. Дескриптор — единственная точка входа в норму. Карточка занятия и ФОС ссылаются на дескриптор РПД (§1.10), не на индикатор ФГОС напрямую. Перевыпуск редакции ФГОС не требует правки ссылок во всех потребителях — только пересвязки дескриптора.
14. УК/ОПК не хранятся в D06 — только ПК. Компетенция УК/ОПК адресуется естественной двойкой (fgos_id, kod) прямо в standards/fgos/data/*.json; локальной строки в D06 не заводится. ПК — единственный тип компетенции, хранимый локально (§1.8), потому что устанавливается самой ОО, а не существует в готовом виде во внешнем документе.
15. Индикатор всегда хранится в ОПОП, никогда — в документе нормы. ФГОС не задаёт индикаторов (проверено на реальных данных — поле всегда пусто). Естественный ключ индикатора — (versiya_opop_id, kod); происхождение (proishozhdenie) — атрибут-дискриминатор, не часть ключа (§1.9).

4. Контракты с другими доменами¶

D06 ↔ D02 (лицензирование)¶

Допустимое множество ОПОП ограничено реестровой записью лицензии (ст. 91): специальность/направление, форма, адрес. ОПОП вне этих границ — невалидна.

D06 ↔ standards/fgos¶

ОПОП ссылается на ФГОС (fgos_id). УК/ОПК и объём/срок импортируются и считаются заданными; локальная правка запрещена (инвариант 2, 4).

D06 → D05 (управление контингентом)¶

Точка сцепки двух осей. Набор несёт ссылку opop_versiya_id (связь «многие-к-одному»: много наборов → одна версия). Пин устанавливается приёмной кампанией по году набора и далее только перецепляется событием траектории (перевод, смена формы, восстановление). Эту ссылку добавляем на шаге 2 в D05.

D06 ↔ D04 (образовательная деятельность)¶

D04 читает структуру пристёгнутой Версии ОПОП как источник обязательств: строки учебного плана → элементы траектории → обязательства. Освоение компетенции (факт D04) сверяется с индикаторами пристёгнутой версии, а не текущей. Потребление — снимком, по паттерну дома.

Форма контроля — норма vs факт. D06 владеет нормой (§1.11): «должен быть модульный контроль темы 3, вес 30, порог 60%». D04 владеет фактом: конкретная попытка на конкретном событии с оценкой. Одна норма D06 порождает множество фактов D04.

D06 → D14 (расписание)¶

D14 разворачивает план запланированных событий D06 на сетку ресурсов (аудитории, преподаватели, потоки). Контракт по докладу §4: «Расписание не создаёт события — оно их разворачивает».

Что передаётся: - Список запланированных учебных событий (§1.12) на период - Их привязки (дисциплина / тема / вид / форма контроля / пакет) - Правила формирования состава (общее правило — «кто имеет это событие в траектории»)

Что НЕ передаётся: - Материалы, формы контроля, gates — их D14 не касается; они читаются D04 напрямую из пакета при проведении

Слот расписания D14 — временной интервал + ресурсы — покрывает 1..N запланированных событий D06. Пример: слот «10:30–12:00 ауд. 301 гр. БИ-25-1 преп. Иванов» может содержать событие «занятие № 14 по D» + событие «модульный контроль темы 3» (у второго — свой состав, часть студентов уже перезачла).

D06 → D05 (траектория)¶

D05 читает план учебных событий D06 (РПД + УП) для формирования траектории обучающегося: развёртка УП с учётом его выборов и перезачётов. Траектория знает, какие события предстоят этому обучающемуся.

Состав события формируется как пересечение (траектория обучающегося содержит это событие) × (статус контингента активен на дату).

5. ERD (mermaid)¶

erDiagram
  OPOP ||--o{ OPOP_Version : "версионируется"
  OPOP }o--|| FGOS : "основан на"
  OPOP_Version ||--|| StudyPlan : "пинит версию"
  OPOP_Version ||--o{ Competency : "пинит ПК (устанавливает ОО)"
  StudyPlan ||--o{ StudyPlanLine : "состоит из"
  StudyPlanLine }o--|| Discipline : "ссылается на"
  StudyPlanLine }o--o| FormaKontrolya : "промежуточная аттестация"
  Discipline ||--o{ WorkProgram : "имеет"
  WorkProgram ||--o{ AssessmentFund : "обеспечен"
  OPOP_Version ||--o{ Indicator : "пинит индикаторы (авторская работа ОО)"
  Indicator }o--o| Competency : "раскрывает ПК (если основание — профстандарт)"
  WorkProgram ||--o{ Descriptor : "формулирует результаты освоения"
  Descriptor }o--|| Indicator : "единственная точка входа в норму"

  WorkProgram ||--o{ PlannedEvent : "планирует события внутри дисциплины"
  StudyPlanLine ||--o{ PlannedEvent : "порождает события уровня программы"
  PlannedEvent }o--o| FormaKontrolya : "закрывает форму"
  PlannedEvent }o--o| Package : "оснащено пакетом"
  Package ||--o{ FormaKontrolya : "содержит формы контроля"
  Package ||--o{ Gate : "имеет шлюзы"

  PlannedEvent {
    enum vid "занятие|модульный_контроль|экзамен|зачёт|курсовая|день_практики|ГИА"
    enum istochnik "РПД|УП"
    duration ozhidaemaya_dlitelnost
    enum forma_provedeniya "очно|онлайн|гибрид"
  }
  Descriptor {
    ref rpd_id
    ref indikator_id "единственная ссылка на норму"
    text tekst "что должен знать/уметь/чем владеть"
    enum vklad "формирует|контролирует"
  }
  Competency {
    ref versiya_opop_id "часть естественного ключа — только ПК"
    string kod "часть естественного ключа"
    string formulirovka
    object proishozhdenie "профстандарт: document_id, put=[funkciya]"
  }
  Indicator {
    ref versiya_opop_id "часть естественного ключа"
    string kod "часть естественного ключа"
    text formulirovka
    object proishozhdenie "discriminator: фгос|пк, document_id/kod_pk, put"
  }
  FormaKontrolya {
    string naimenovanie
    enum uroven "занятие|тема|модуль|дисциплина|программа"
    enum sposob_zakrytiya "прямой|агрегированный"
    enum rol_v_reytinge "обязательная|повышающая"
    number ves
  }
  Package {
    string versiya
    string revisiya
    string schema_versiya
    duration ozidayemaya_dlitelnost
  }
  Gate {
    enum vid "entry-test|consent|briefing|readiness|form|attendance"
    string tekst_versiya "версия текста"
    enum razmeshchenie "entry|exit"
  }

Внешняя сцепка (за пределами D06): - D05.Набор }o--|| OPOP_Version : "пин по году набора" - D14.Слот }o--o{ PlannedEvent : "разворачивает 1..N событий на слот" - D05.Траектория }o--o{ PlannedEvent : "включает события для обучающегося" - D04.УчебноеСобытие(факт) }o--|| PlannedEvent : "реализация плана" - Indicator.proishozhdenie }o--|| standards/fgos.Competency : "адресуется двойкой (fgos_id, kod), если основание — ФГОС; локальной строки Компетенции для УК/ОПК в D06 нет"

Матрица компетенций не показана как сущность ERD — это вычисляемый вид (StudyPlanLine × Competency, агрегация через WorkProgram → Descriptor → Indicator → Competency), а не хранимая таблица.