Рабочая ситуация
Два подразделения вели учёт отдельно: разные идентификаторы, дубли контрагентов, несогласованные единицы измерения и поля с одинаковыми названиями, но разным смыслом. Теперь учёт объединяют, и терять записи нельзя.
Студент уточняет смысл полей у ИИ-владельца данных, строит целевую схему, пишет правила сопоставления и выполняет миграцию в изолированной базе. После первой успешной сверки сценарий подаёт проблемную выгрузку: новые дубли, записи вне ожидаемых диапазонов, нарушенные связи. Нужно исправить правила, проверить сохранность данных и выполнить учебный откат.
Рабочее место
- SQL-клиент по логике DBeaverдерево объектов, ER-диаграмма, SQL-редактор и просмотр результатов.
- Изолированная учебная база данныхисполнение миграций с контрольными транзакциями и ограничениями.
- Рабочий мессенджервопросы владельцу данных и аналитику, согласование неоднозначных правил.
Как проходит работа
- Изучить обе схемы и примеры записей; собрать список неоднозначностей.
- Уточнить семантику полей и правила приоритета источников у ИИ-коллег.
- Спроектировать целевую ER-модель и ограничения целостности.
- Написать и выполнить миграцию, провести сверку по контрольным суммам и количествам.
- Обработать проблемную выгрузку: исправить правила, повторить сверку, выполнить откат по протоколу.
ИИ-команда
- Владелец данныхзнает, что означают поля на практике и какой источник считать главным при конфликте.
- Аналитик подразделенияприносит примеры реальных записей и исключений, замечает потери в отчётах.
- Администратор учебной базы данныхзадаёт требования к транзакциям, ограничениям и порядку отката.
Что проверяется
| Итоговый артефакт | Автоматическая проверка в заданных границах | Оценка преподавателя |
|---|---|---|
| ER-модель, SQL, миграция, сверка и откат | Исполнение в изолированной БД: контрольные транзакции, ограничения, сохранность истории и результат отката | Обоснование семантики и неоднозначных правил сопоставления данных |
Связанные дисциплины
Тренажёр подходит для дисциплин по управлению данными, базам данных и теории информации; может открывать проектный модуль как шаг «потребность → модель данных».
Общая механика серии
- Рабочая ситуациясинтетические документы, данные, сроки и противоречия образуют конкретную задачу, а не свободную беседу.
- Ролевой мессенджерзаказчик, оператор, разработчик или эксплуатация располагают только сведениями своей роли; допустимые факты сценария заданы заранее.
- Первый результатстудент создаёт спецификацию, схему, код, модель или прототип, который можно сохранить и проверить.
- Изменение условийсценарный движок вводит новую версию контракта, ограничение, возмущение или новые данные; ИИ не придумывает эти события самостоятельно.
- Пересмотрстудент обновляет решение, повторяет проверки и объясняет, почему изменил или сохранил первоначальный подход.
- Безопасное исполнениепользовательский код и SQL запускаются только в изолированной среде; реальные секреты, персональные данные и производственные системы не нужны.
Ролевые ИИ-персонажи не получают скрытый ключ проверки и не выставляют итоговые баллы: вычисляемую часть результата проверяет программное ядро, открытое инженерное решение оценивает преподаватель по заранее известной рубрике.
Статус описания: Проектируется. На странице описан проектируемый тренажёр — целевой учебный сценарий, а не готовое приложение. Состав воспроизводимых сред, механика и критерии проверки согласуются с вузом; реализация и приёмка выполняются отдельно.
Названия и логотипы сторонних платформ обозначают учебные профили интерфейсов и операций и не означают поставку оригинальных продуктов, интеграцию с ними, партнёрство или одобрение правообладателей. Упоминание программ Топ-ИТ и «Приоритет-2030» обозначает область применения тренажёра, а не официальное включение в эти программы.
