Delivered at:: Department of Information Technologies in Business (Faculty of Computer Science, Economics, and Social Sciences)

Course type:: Compulsory course

When:: 2 year, 1, 2 module

Дополнительные материалы в LMS Задать вопрос

Аннотация

Курс предназначен для смешанной аудитории студентов направлений «Бизнес-информатика» и «Программная инженерия». В нём соблюдается баланс между проектированием и разработкой: студенты учатся как обосновывать модели и архитектурные решения, так и реализовывать, проверять и развивать их в работающей системе. Дисциплина формирует системное представление о данных как о модели предметной области, рабочем состоянии цифрового продукта и основании для аналитики и принятия решений. Курс объединяет операционную и аналитическую перспективы: от бизнес-процесса, backend и OLTP-базы до загрузки данных, аналитической витрины, метрик и BI. В операционной части студенты проектируют реляционные схемы, выражают бизнес-правила ограничениями, реализуют миграции, анализируют конкурентные сценарии и выбирают границы применения реляционного и полуструктурированного хранения. В аналитической части студенты прослеживают происхождение данных, проектируют витрины, применяют SQL-паттерны, формализуют метрики и оценивают ограничения интерпретации. Содержание раскрывается от общего к частному в трёх слоях: обзор ландшафта работы с данными; углублённый обзор OLTP/backend и OLAP/аналитики; рабочие навыки в каждой из этих сфер. Обзорные темы формируют системное понимание того, какие решения, когда и почему следует применять, а практические — навыки их реализации и проверки. Курс организован итеративно: база данных рассматривается как развивающаяся часть информационной системы, а не как однократно создаваемая «идеальная» схема. Студенты принимают решения при неполных требованиях, а затем адаптируют их к новым задачам. Проектные решения оцениваются не как единственно правильные, а с учётом контекста, допущений, альтернатив и последствий. SQL используется как средство рассуждения о данных, а не как самоцель. Основной практической СУБД является PostgreSQL, однако результаты обучения не привязаны к одному продукту и не ориентированы на подготовку администратора баз данных.

Цель освоения дисциплины

Студент, освоивший дисциплину, должен: ●Целостно понимать ландшафт работы с данными, связи между OLTP и OLAP и роли данных на пути от бизнес-процесса до принятия решения. ●Уметь сочетать проектирование и разработку: переводить требования и бизнес-правила в модели данных, обосновывать выбор решения, реализовывать и проверять его. ●Уметь последовательно развивать базу данных в условиях неполных и изменяющихся требований, сохраняя данные, целостность и корректность работы системы. ●Понимать необходимость ответственного отношения к проектным и инженерным решениям: умение фиксировать допущения, сравнивать альтернативы, объяснять последствия и выполнять обоснованный рефакторинг.

Планируемые результаты обучения

Студент знает общий ландшафт работы с данными, различия и связь между операционным и аналитическим контурами информационной системы; принципы реляционного и гибридного хранения, целостности, миграций, транзакций и конкурентной работы; основы происхождения и преобразования данных, аналитического моделирования, SQL, метрик и BI.
Студент понимает, какие классы решений, когда и почему применяются, а также как проектные и инженерные решения зависят от контекста, каковы их ограничения и долгосрочные последствия.
Студент умеет переходить от бизнес-требований к проектному решению и его технической реализации: моделировать предметную область и реализовывать операционную схему; обеспечивать целостность и корректность конкурентных операций; обоснованно выбирать модель хранения; преобразовывать операционные данные в аналитическую витрину, писать и проверять SQL-запросы, определять метрики и представлять их в BI.
Студент умеет работать над базой данных итеративно: реализовывать решение при неполных требованиях; изменять заполненную базу с помощью проверяемых миграций; фиксировать допущения; сравнивать альтернативы; анализировать последствия предыдущих решений; выполнять обоснованный рефакторинг и защищать принятые решения.

Содержание учебной дисциплины

Раздел 1. Общий ландшафт работы с данными.
Раздел 2. OLTP и backend: операционные данные и развитие системы.
Раздел 3. OLAP, аналитическое моделирование и принятие решений

Элементы контроля

Контрольная точка 1
Контрольная точка 2
Контрольная точка 3
Контрольная точка 4
Экзамен
Команда из 3–4 студентов выбирает или предлагает предметную область: компьютерный клуб, онлайн-медицина, аренда парковочных мест, бронирование переговорных, прокат автомобилей, образовательная платформа, доставка, фитнес-клуб либо иной согласованный цифровой продукт. Задача команды — провести информационную систему через три последовательные версии, сохранив данные, объяснив принятые решения и приняв ответственность за их последствия. Роль участника определяется как зона лидерства, а не освобождение от изучения других частей проекта. Допускаются роли архитектора, разработчика, инженера данных, аналитика, продуктового аналитика, системного аналитика, BI-разработчика и менеджера проекта; смена ролей между этапами поощряется. Проект выполняется в течение заключительной части курса и экзаменационной сессии. На защите команда демонстрирует работоспособный основной сценарий и эволюцию схемы. Каждый студент отдельно отвечает на вопросы по модели, миграциям, конкурентным или аналитическим решениям, своему вкладу и последствиям решений. Разрешается использовать собственную документацию проекта, SQL-код и официальную документацию применяемых технологий. Структура экзаменационной работы: 1.Этап 1. MVP. Команда реализует минимальный законченный бизнес-сценарий и первую версию модели, фиксируя границы предметной области и допущения. 2.Этап 2. New feature. Команда получает существенное изменение требований, изменяет существующую модель без пересоздания базы, пишет миграцию, сохраняет данные и объясняет последствия решений первого этапа. 3.Этап 3. New feature или Refactoring. Команда реализует новый сценарий либо устраняет выявленную проблему: ограничение модели, конкурентную ошибку, невозможность рассчитать исторический показатель, недостаточную производительность аналитического запроса или другое последствие предыдущего решения. Добавление новых сущностей не является обязательным. 4.Аналитический контур. Команда формулирует не менее одного бизнес-вопроса, создаёт аналитическое представление или витрину на основе операционных данных, рассчитывает предметно определённую метрику и объясняет ограничения интерпретации. 5.Командная демонстрация и индивидуальная защита. Команда показывает эволюцию продукта и данные между версиями; каждый участник подтверждает вклад и рефлексирует над решениями и последствиями. Общие артефакты: ●краткое описание продукта и границы предметной области; ●актуальная ER-диаграмма; ●итоговая версия схемы; ●итоговая презентация. Поэтапные артефакты для каждого релиза: ●новые или изменившиеся требования; ●актуализированная модель; ●SQL-миграция; ●описание принятых решений и последствий; ●тестовые или демонстрационные сценарии. Индивидуальные артефакты: ●отчёт по личному вкладу в каждый этап; ●конкретные подтверждения вклада: миграция, часть модели, SQL-запросы, тест конкурентного сценария, аналитическая витрина, дерево метрик, BI-макет, архитектурное решение, рефакторинг или анализ данных.

Промежуточная аттестация

2026/2027 2nd module
0.1 * Контрольная точка 1 + 0.1 * Контрольная точка 4 + 0.1 * Контрольная точка 3 + 0.1 * Контрольная точка 2 + 0.6 * Экзамен

Список литературы

Авторы

Карпович Марина Валерьевна

Bachelor’s Programme 'IT System Development for Business'

Databases

Программа дисциплины