Презентация к курсовой «Разработка базы данных для учёта заказов»

• Тема: база данных для учёта заказов
• Автор: Ковалёв Артём, ИСП-31
• Цель — автоматизация учёта заказов
• Дальше — актуальность работы

Добрый день, уважаемая комиссия! Представляю вашему вниманию курсовую работу на тему «Разработка базы данных для учёта заказов интернет-магазина». Меня зовут Ковалёв Артём, я студент группы ИСП-31. В ходе работы я спроектировал и реализовал базу данных, которая автоматизирует учёт заказов и повышает эффективность работы магазина.

• Рост заказов: 150 → 4500 в месяц
• Поиск замедлился: 2 → 45 секунд
• Ошибки удвоились
• Вывод: нужна база данных

Раньше, когда заказов было немного, электронные таблицы вполне справлялись. Но с ростом объёма до 4500 заказов в месяц всё меняется: поиск нужного заказа занимает до 45 секунд, а доля ошибок при ручном вводе удваивается. Это приводит к задержкам и недовольству клиентов. Поэтому возникает необходимость в автоматизированной базе данных, которая обеспечит быстрый и надёжный учёт.

• Цель — БД для учёта заказов
• Задачи: анализ, модель, реализация, тестирование
• Дальше — объект и предмет

Цель нашей работы — разработать базу данных для учёта заказов интернет-магазина. Для её достижения мы поставили четыре задачи: сначала проанализировать предметную область и существующие решения, затем спроектировать логическую модель базы данных, после — реализовать её в выбранной СУБД и, наконец, провести тестирование и оценить эффективность. Каждая задача соответствует отдельному этапу работы, результаты которых мы представим далее.

• Объект — процесс учёта заказов
• Предмет — методы и средства проектирования БД
• Фокус на автоматизации процесса
• Дальше — обзор существующих решений

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

• Сравнили 3 варианта
• Самописная БД — низкая стоимость, высокая гибкость
• Коробочное — быстро, но дорого и негибко
• Облако — среднее по всем параметрам
• Выбор: самописная БД

Для учебного проекта сравнили собственный прототип, коробочное решение и облачный сервис. Открытая СУБД позволяет не платить лицензионные сборы, но разработка, тестирование и сопровождение требуют работы. Собственную модель выбрали для практики проектирования; это не универсально самый дешёвый вариант для бизнеса.

• Клиент 1: NЗаказ
• Заказ 1: NПозиция; Товар 1: NПозиция
• СоставнойPKпозиции
• Заказ 1:0..1 Доставка

В модели пять таблиц. Клиент имеет много заказов. Позиция заказа хранит внешние ключи на Заказ и Товар, количество и цену при покупке; первичный ключ составной из идентификаторов заказа и товара. Так раскрывается связь многие ко многим. Текущая цена товара может измениться, поэтому историческая цена хранится в позиции. Доставка ссылается на Заказ уникальным внешним ключом: у заказа ноль или одна доставка. Сумма заказа вычисляется по позициям.

• Пятьтаблицкакнасхеме
• Позиция: составнойPK+дваFK
• CHECKдляколичестваицен
• Транзакциядобавлениязаказа

PostgreSQL хранит пять показанных таблиц. Клиент, Заказ, Товар и Доставка имеют собственные id. Позиция заказа использует составной первичный ключ; отдельный автоинкрементный id не обязателен. Внешние ключи обеспечивают ссылочную целостность, CHECK ограничивает количество и цены. Заказ и позиции добавляются в одной транзакции. Частичные отгрузки и несколько складов требуют расширения модели.

• 10 000 записей, 320 мс → 45 мс
• Ускорение в 7 раз
• Сценарии: добавление, поиск, обновление, удаление
• Индексы — ключ к производительности

В условном тесте один запрос выполняется 320 миллисекунд без индексов и 45 с индексами: ускорение около 7,1 раза. Для реального измерения нужны одинаковые данные, EXPLAIN ANALYZE, повторы запроса и контроль кэша. Индексы выбираются под соединения и фильтрацию, а их эффект проверяется на конкретной нагрузке.

• 4500 заказов в месяц
• отчёт 30 → 2 мин, в 15 раз
• ошибки учёта -40%
• дальше — выводы и развитие

Учебный сценарий предполагает обработку 4500 заказов в месяц. Отчёт формируется за 2 минуты вместо 30, доля ошибок снизилась на 40 процентов. Эти условные показатели иллюстрируют критерии оценки, но не являются результатами измерения действующего магазина. Нагрузочный тест должен отдельно подтвердить пропускную способность и отсутствие ошибок.

• Пять согласованных таблиц
• 320 → 45 мс — условный тест
• Оплата, приложение, аналитика
• Частичные отгрузки: расширение модели

Прототип поддерживает основной сценарий клиента, заказа, позиций и одной доставки. Пять таблиц согласованы с логической схемой. Условный тест индексации показывает 320 и 45 миллисекунд, ускорение около 7,1 раза. Реальные результаты требуют испытаний на одинаковой нагрузке. Следующие направления: онлайн-оплата, клиентское приложение, аналитика и частичные отгрузки.