Проектирование реляционной базы данных для автоматизации учета товаров в розничном магазине

В условиях современной конкуренции ручной учет товаров, продаж и остатков становится главным тормозом для любого розничного магазина. Он ведет к ошибкам, замедляет обслуживание и не позволяет принимать оперативные управленческие решения. Автоматизация этих процессов с помощью баз данных (БД) — не просто технологическое обновление, а ключевое условие для выживания и роста бизнеса. Она позволяет централизовать хранение данных, оптимизировать управление запасами и мгновенно формировать необходимую отчетность.

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

• Проанализировать предметную область и сформулировать функциональные требования к системе.
• Спроектировать концептуальную модель данных в виде ER-диаграммы.
• Разработать логическую модель, приведя структуру таблиц к третьей нормальной форме (3НФ).
• Реализовать спроектированную структуру средствами выбранной системы управления базами данных (СУБД).
• Разработать и выполнить тестовые SQL-запросы для демонстрации работоспособности системы.

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

Глава 1. Анализ предметной области и определение функциональных требований

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

• Товары: основной объект учета с его атрибутами (цена, артикул, остаток).
• Поставщики: компании или лица, поставляющие товары.
• Клиенты: покупатели, совершающие заказы.
• Заказы (Продажи): факты совершения покупки.
• Категории товаров: для удобной классификации ассортимента.

Основные бизнес-процессы, подлежащие автоматизации, включают приемку товара от поставщика, его продажу клиенту (оформление заказа), учет актуальных остатков на складе и списание в случае брака или порчи. Исходя из этого анализа, мы можем сформулировать четкие функциональные требования к будущей базе данных. Система должна обеспечивать выполнение следующих задач:

1. Хранение полной информации о товарах, их категориях и поставщиках.
2. Регистрация и учет операций прихода и продажи товаров.
3. Ведение базы клиентов и истории их покупок.
4. Предоставление актуальной справочной информации о наличии товаров.
5. Формирование данных для кассового чека по конкретной продаже.

Теперь, когда мы точно знаем, что система должна делать, мы можем приступить к визуализации ее структуры на концептуальном уровне с помощью ER-диаграммы.

Глава 2. Концептуальное проектирование, или Как построить ER-диаграмму

Концептуальная модель — это фундамент нашей базы данных. Она создается с помощью ER-диаграммы (Entity-Relationship Diagram), которая наглядно показывает основные сущности системы и логические связи между ними. ER-диаграмма является универсальным «чертежом», понятным как разработчику, так и заказчику.

Основываясь на анализе из предыдущей главы, мы выделяем следующие ключевые сущности:

• Товары (Products)
• Категории (Categories)
• Поставщики (Suppliers)
• Клиенты (Clients)
• Заказы (Orders)

Каждая сущность обладает набором атрибутов. Например, для сущности Товары это могут быть: ID_Товара (уникальный идентификатор), название, артикул, цена, остаток_на_складе, ID_Категории, ID_Поставщика. Главный шаг — определить связи между этими сущностями:

• Один-ко-многим (1:М): Один поставщик может поставлять много товаров, но каждый товар поставляется только одним поставщиком. Аналогично, одна категория объединяет много товаров, и один клиент может сделать много заказов.
• Многие-ко-многим (М:М): Один заказ может содержать много разных товаров, и один и тот же товар может присутствовать во многих заказах.

Такую связь, как «Заказ-Товар» (М:М), нельзя реализовать напрямую в реляционной модели. Для этого вводится промежуточная (ассоциативная) таблица, которая связывает заказ и товар, храня ID заказа, ID товара, а также количество и цену товара в конкретном заказе.

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

Глава 3. Логическое проектирование, или Почему важна нормализация данных

На этапе логического проектирования мы переходим от абстрактной ER-диаграммы к конкретной структуре таблиц реляционной БД. Здесь мы определяем точный состав полей, типы данных и, что самое важное, ключи, которые обеспечат целостность нашей системы.

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

1. categories — справочник категорий товаров.
2. suppliers — справочник поставщиков.
3. products — каталог товаров.
4. clients — база клиентов.
5. orders — информация о заказах (продажах).
6. order_items — связующая таблица для позиций в заказе.

Для каждой таблицы определяется первичный ключ (Primary Key, PK) — уникальный идентификатор записи (например, `category_id` в таблице `categories`). Связи между таблицами реализуются через внешние ключи (Foreign Key, FK). Например, в таблице `products` будет поле `category_id`, которое ссылается на запись в таблице `categories`. Это гарантирует, что нельзя добавить товар с несуществующей категорией.

Центральным процессом на этом этапе является нормализация — процесс организации данных для минимизации их избыточности. Мы приводим нашу структуру к третьей нормальной форме (3НФ), что позволяет устранить аномалии данных. Например, без нормализации название категории могло бы храниться в каждой строке товара. При изменении названия категории пришлось бы обновлять множество записей, что чревато ошибками. Нормализация решает эту проблему: название хранится в одном месте (в таблице `categories`), а товары просто на него ссылаются. Этот подход критически важен, так как эффективная структура БД повышает целостность данных и снижает риски их несогласованности.

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

Глава 4. Физическая реализация средствами SQL, или Воплощаем проект в коде

Физическое проектирование — это этап, на котором логическая модель превращается в реальные объекты базы данных с помощью языка SQL (Structured Query Language). В качестве СУБД для нашего проекта выберем PostgreSQL — это мощная, бесплатная и широко распространенная система с открытым исходным кодом, идеально подходящая для учебных и коммерческих задач. Другими популярными вариантами могли бы быть MySQL или MS Access.

Ниже представлен SQL-код (DDL, Data Definition Language) для создания всех необходимых таблиц. В коде прокомментирован выбор типов данных:

• BIGINT или SERIAL для первичных ключей — обеспечивает автоматическое увеличение номера.
• VARCHAR(n) для текстовых строк ограниченной длины (названия, артикулы).
• DECIMAL(10, 2) для денежных значений — гарантирует точность вычислений.
• INT для целых чисел (количество).
• TEXT для длинных описаний.
• TIMESTAMP для фиксации даты и времени.

Особое внимание уделено определению внешних ключей с директивой ON DELETE RESTRICT, которая запрещает удаление, например, категории, если на нее ссылаются товары. Это обеспечивает целостность данных на уровне самой СУБД.

-- Создание таблицы категорий
CREATE TABLE categories (
    category_id BIGINT PRIMARY KEY,
    name VARCHAR(255) NOT NULL
);

-- Создание таблицы поставщиков
CREATE TABLE suppliers (
    supplier_id BIGINT PRIMARY KEY,
    name VARCHAR(255) NOT NULL,
    contact_info TEXT
);

-- Создание таблицы товаров
CREATE TABLE products (
    product_id BIGINT PRIMARY KEY,
    name VARCHAR(255) NOT NULL,
    article VARCHAR(50) UNIQUE NOT NULL,
    price DECIMAL(10, 2) NOT NULL,
    stock_quantity INT NOT NULL DEFAULT 0,
    category_id BIGINT,
    supplier_id BIGINT,
    FOREIGN KEY (category_id) REFERENCES categories (category_id) ON DELETE RESTRICT,
    FOREIGN KEY (supplier_id) REFERENCES suppliers (supplier_id) ON DELETE RESTRICT
);

-- И так далее для остальных таблиц...

Каркас базы данных создан. Теперь его нужно наполнить тестовыми данными и проверить в работе, выполнив запросы, которые решают наши изначальные бизнес-задачи.

Глава 5. Тестирование работоспособности через практические SQL-запросы

Созданная структура бесполезна без данных. Чтобы проверить ее функциональность, сначала наполним таблицы тестовой информацией с помощью команд INSERT INTO.

-- Добавим пару категорий
INSERT INTO categories (category_id, name) VALUES (1, 'Смартфоны'), (2, 'Ноутбуки');

-- Добавим товар
INSERT INTO products (product_id, name, article, price, stock_quantity, category_id, supplier_id) 
VALUES (101, 'Смартфон "Фотон-М"', 'PH-M-2025', 25000.00, 50, 1, 1);

-- Добавим клиента и заказ
INSERT INTO clients (client_id, full_name) VALUES (1, 'Иванов Иван Иванович');
INSERT INTO orders (order_id, client_id, order_date) VALUES (1, 1, '2025-08-12 15:30:00');

-- Добавим позицию в заказ
INSERT INTO order_items (order_id, product_id, quantity, price_per_item) VALUES (1, 101, 2, 25000.00);

Теперь, когда в БД есть данные, мы можем выполнить несколько SELECT-запросов, которые напрямую отвечают на бизнес-задачи, поставленные в Главе 1.

1. Получение списка всех товаров из категории «Смартфоны»:

SELECT name, article, price, stock_quantity
FROM products p
JOIN categories c ON p.category_id = c.category_id
WHERE c.name = 'Смартфоны';

2. Формирование данных для товарного чека по заказу №1: Этот запрос объединяет (JOIN) несколько таблиц, чтобы собрать полную информацию о заказе.

SELECT 
    o.order_id,
    o.order_date,
    p.name,
    oi.quantity,
    oi.price_per_item,
    (oi.quantity * oi.price_per_item) AS total_position_sum
FROM orders o
JOIN order_items oi ON o.order_id = oi.order_id
JOIN products p ON oi.product_id = p.product_id
WHERE o.order_id = 1;

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

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

В ходе выполнения данной курсовой работы была успешно достигнута поставленная цель: спроектирована и реализована реляционная база данных для автоматизации учета в розничном магазине. Для этого были последовательно решены все ключевые задачи. Был проведен детальный анализ предметной области, на основе которого спроектированы концептуальная (ER-диаграмма) и логическая модели данных. Структура таблиц была приведена в соответствие с требованиями третьей нормальной формы, что обеспечивает снижение избыточности и повышение целостности данных.

На физическом уровне структура была реализована средствами СУБД PostgreSQL, а ее работоспособность проверена набором практических SQL-запросов, которые решают основные бизнес-задачи: от получения справочной информации до формирования данных для чека. Таким образом, можно сделать вывод, что цель работы полностью достигнута. Созданная база данных является надежным фундаментом для дальнейшей разработки комплексной информационной системы. Возможные пути для ее развития включают:

• Добавление модуля управления персоналом (продавцы, менеджеры).
• Разработку системы лояльности клиентов (скидки, бонусы).
• Интеграцию с фронтенд-приложением или веб-сайтом магазина.

Список использованной литературы и полезные ресурсы

При подготовке курсовой работы рекомендуется опираться на фундаментальные труды в области баз данных и использовать современные онлайн-инструменты.

Пример списка литературы (в формате ГОСТ):

1. Дейт, К. Дж. Введение в системы баз данных / К. Дж. Дейт. – 8-е изд. – М.: Вильямс, 2018. – 1328 с.
2. Коннолли, Т. Базы данных. Проектирование, реализация и сопровождение. Теория и практика / Т. Коннолли, К. Бегг. – 3-е изд. – М.: Вильямс, 2016. – 1440 с.
3. Грофф, Дж. Р. SQL: полное руководство / Дж. Р. Грофф, П. Н. Вайнберг. – 3-е изд. – М.: Вильямс, 2021. – 960 с.

Полезные онлайн-ресурсы:

• Официальная документация PostgreSQL: postgresql.org/docs/ — самый надежный источник информации.
• Инструменты для ER-диаграмм: draw.io (бесплатный) или Lucidchart — для визуального проектирования.
• Образовательные порталы: SQL-Academy, SQLBolt — для интерактивной практики написания запросов.

Список использованной литературы

1. Балиер Э. Профессиональное программирование в Microsoft Office Access 2003: [пер. с англ.] /Э. Балтер.- М.: Вильямс, 2006. — 1296 с.
2. Блюттман К. Access. Трюки: Оригинальные решения задач по обработке данных: [пер. с англ.] / К. Блюттман. – СПб.: Питер, 2006. – 331 с.
3. Бьер М. Интеллектуальное ведение и сопровождение бизнеса: [пер. с англ.] / М. Бьер. – М.: КУДИЦ-ОБРАЗ, 2005. – 240 с.
4. Золотова С.И. Практикум по Access: Подготовительный курс, предваряющий более глубокое изучение технологии баз данных / С.И. Золотова. – М.: Финансы и статистика, 2006. – 143 с.
5. Хансен Г. Базы данных: разработка и управление: [пер. с англ.] / Г. Хансен, Дж. Хансен. – М.: БИНОМ, 1999. — 704 с.