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

Введение: Актуальность, цели и задачи автоматизации сбытовой деятельности

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

Именно поэтому актуальность перехода к специализированной Информационной Системе (ИС) для автоматизации сбытовой деятельности на современном предприятии является неоспоримой. Цель разработки такой системы — создание единого рабочего пространства, централизованного хранения информации и систематизации всех рутинных операций для увеличения прибыли и повышения лояльности клиентов.

В рамках данной работы ставятся следующие ключевые задачи:

1. Провести анализ предметной области, выявив основные функции и бизнес-процессы отдела сбыта, подлежащие автоматизации.
2. Разработать концептуальную (инфологическую) и логическую модели базы данных на основе методологии ER-моделирования и принципов нормализации.
3. Обосновать выбор технологической платформы и СУБД, учитывая современные требования, включая отечественные решения.
4. Оценить ожидаемую экономическую эффективность и проанализировать потенциальные риски внедрения разработанной ИС.

Определение ключевых терминов

Для построения надежной методологии необходимо установить точный академический аппарат:

• Отдел сбыта (Отдел продаж): Это подразделение предприятия, отвечающее за реализацию готовой продукции — товаров, произведенных предприятием и предназначенных для продажи. Его функции включают взаимодействие с клиентами, заключение договоров, оформление поставок и контроль дебиторской задолженности.
• База данных (БД): Это информационная структура, отражающая состояние объектов предметной области и их отношения, реализованная посредством вычислительной техники. Она является основой для любой информационной системы.
• Информационная система (ИС): Это интегрированная система, предназначенная для сбора, хранения, обработки, поиска и распространения информации, поддерживающая принятие решений и управление бизнес-процессами.
• Система управления базами данных (СУБД): Это комплекс программ, который позволяет создать базу данных и управлять данными (вставлять, обновлять, удалять, выбирать), обеспечивая безопасность, надежность хранения и целостность данных.
• ER-модель (Модель «сущность-связь»): Это модель данных, позволяющая описывать концептуальные схемы предметной области. Используется при высокоуровневом проектировании баз данных для выделения ключевых сущностей и связей между ними.
• Реляционная модель: Это модель данных, в которой данные хранятся в виде двумерных таблиц (отношений), связанных между собой через общие столбцы (ключи).

Теоретические основы и методологии проектирования баз данных

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

Жизненный цикл и фазы проектирования БД

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

1. Концептуальное (инфологическое) проектирование:
   Это начальный и наиболее важный этап. На этой фазе строится семантическая модель предметной области, которая абсолютно независима от конкретной СУБД и модели данных. Цель — понять, какая информация нужна. Результатом является концептуальная модель, описывающая информационные объекты (сущности), их атрибуты и ограничения целостности, чаще всего выраженная в форме ER-модели. Ошибки, допущенные на этом этапе, наиболее трудно выявляются и устраняются на последующих этапах, причем стоимость их исправления может быть в 5–7 раз выше, если дефект обнаружен уже в процессе тестирования или внедрения.
2. Логическое проектирование:
   На этом этапе концептуальная модель преобразуется в модель данных, соответствующую выбранной модели организации данных (в нашем случае, реляционной), но еще без учета специфики конкретной СУБД (например, SQL Server или PostgreSQL). Здесь применяется процесс нормализации, и определяются первичные и внешние ключи.
3. Физическое проектирование:
   Это заключительная фаза, где создается описание реализации базы данных на вторичных носителях информации. Сюда входят выбор конкретной СУБД, определение типов данных, создание индексов для оптимизации запросов, внедрение ограничений целостности (триггеров) и мер безопасности.

Моделирование данных: ER-модель и Нормализация

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

Модель «Сущность-Связь» (ER-модель)

ER-модель, предложенная Питером Ченом в 1976 году, является краеугольным камнем концептуального проектирования. Она позволяет визуально представить структуру предметной области:

• Сущности (основные объекты, о которых нужно хранить данные, например, Покупатели, Товары). В нотации Чена обозначаются прямоугольниками.
• Атрибуты (характеристики сущностей, например, Телефон для сущности Покупатели). Обозначаются эллипсами.
• Связи (взаимодействие между сущностями, например, «Оформил» между Покупателем и Заказом). Обозначаются ромбами.

Ключевые типы связей, которые будут использоваться в ИС отдела сбыта:

• Один-ко-многим (1:N): Один покупатель может оформить много заказов, но каждый заказ оформлен только одним покупателем.
• Многие-ко-многим (N:M): Один заказ может включать много товаров, и один товар может быть включен во много заказов.

Нормализация реляционной модели

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

В большинстве коммерческих систем достаточно достичь Третьей нормальной формы (3НФ). Разве можно пренебречь этим этапом? Отсутствие нормализации неминуемо приведет к логическим ошибкам в данных, когда, например, при изменении цены товара в одной записи, она останется старой в другой, что делает систему ненадежной для финансового учета.

Нормальная Форма	Требование	Суть
Первая НФ (1НФ)	Атомарность данных	Все атрибуты должны быть атомарными (неделимыми). В ячейке не может быть списка или массива значений.
Вторая НФ (2НФ)	Зависимость от полного ключа	Каждый неключевой атрибут должен зависеть от всего первичного ключа (актуально для таблиц с составным ключом).
Третья НФ (3НФ)	Отсутствие транзитивной зависимости	Отсутствие транзитивной зависимости, то есть неключевые атрибуты должны зависеть только от первичного ключа, а не от других неключевых атрибутов. Например, вынос названия категории в отдельную таблицу, чтобы оно не зависело от ID_Категории, который сам не является первичным ключом.

Анализ предметной области: Функции и бизнес-процессы отдела сбыта

Для успешного проектирования ИС необходимо провести глубокое погружение в деятельность отдела сбыта, определив, что именно должно быть автоматизировано.

Ключевые функции отдела сбыта и их взаимодействие

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

1. Управление клиентской базой (CRM-функция): Ведение справочника покупателей (оптовых клиентов, дилеров, дистрибьюторов) с фиксацией контактных данных, истории взаимодействия и условий договоров.
2. Обработка заказов и сделок: Прием, регистрация и квалификация входящих заявок. Формирование коммерческих предложений, счетов и договоров.
3. Управление отгрузками: Планирование и оформление своевременной поставки готовой продукции. Контроль за перемещением товара со склада до клиента.
4. Финансовый контроль: Отслеживание оплаты, контроль за дебиторской задолженностью и проведение мероприятий по ее ликвидации.
5. Взаимодействие с производством и складом: Контроль товарных остатков, резервирование продукции и передача информации о необходимых объемах производства.
6. Аналитика и отчетность: Формирование оперативных и сводных отчетов по продажам, эффективности менеджеров, воронке продаж и клиентской активности.

Автоматизация этих функций позволяет создать единое информационное пространство, упрощая работу с клиентами на каждом этапе воронки продаж.

Детализация бизнес-процессов сбыта

Современный сбыт, особенно в B2B-сегменте (Business-to-Business), представляет собой структурированную последовательность действий, известную как воронка продаж. Автоматизация должна поддерживать и контролировать прохождение сделки по всем этапам:

Этап Воронки	Ключевые действия, подлежащие автоматизации	Функционал ИС
1. Привлечение и Генерация Лидов	Сбор и сортировка входящих заявок (email, звонки, веб-формы). Первичная обработка и классификация запросов.	Автоматическое создание карточки клиента/сделки, привязка к источнику лида.
2. Квалификация и Взращивание	Оценка потенциального клиента (потребность, бюджет, полномочия). Планирование звонков, встреч, рассылок.	Распределение задач, напоминания о задачах, ведение истории взаимодействия.
3. Презентация и Работа с Возражениями	Формирование коммерческих предложений и договоров. Управление версиями документов.	Генерация документов по шаблонам, автоматическая отправка клиенту.
4. Заключение Сделки и Адаптация	Фиксация факта продажи, выставление счета, оформление отгрузочных документов.	Изменение статуса сделки, контроль оплаты, передача заказа в отдел логистики.

Интеграция с управлением запасами: Оптимальный размер заказа (EOQ)

Критически важной функцией отдела сбыта является контроль за товарными остатками для избежания чрезмерных излишков или дефицита продукции. Информационная система сбыта должна быть интегрирована со складским учетом.

Одним из наиболее эффективных аналитических инструментов, который может быть встроен в ИС, является расчет Оптимального Размера Заказа (Economic Order Quantity, EOQ), или формулы Уилсона. Этот расчет позволяет минимизировать совокупные издержки, связанные с закупкой (или запуском в производство) и хранением готовой продукции. Встраивание этого инструмента позволяет ИС не только регистрировать продажи, но и формировать обоснованные рекомендации для отдела снабжения или производства, что повышает стратегическую ценность системы.

Формула Уилсона (EOQ):

Qopt = √(2 ⋅ D ⋅ K / H)

Где:

• Qopt — оптимальный размер заказа.
• D — годовой объем спроса (потребуется интеграция с историческими данными продаж).
• K — затраты на размещение одного заказа (или затраты на запуск одной партии производства).
• H — стоимость хранения единицы товара в год.

Разработка структуры базы данных для ИС отдела сбыта

Центральным элементом информационной системы является база данных, спроектированная в соответствии с реляционной моделью.

Концептуальная ER-диаграмма

На основе анализа предметной области были выделены ключевые сущности, необходимые для функционирования ИС отдела сбыта:

Сущность	Атрибуты (примеры)	Назначение
Покупатели	ID_Покупателя (PK), Наименование, Адрес, Телефон, Контактное_лицо, Тип_клиента (Опт/Розница)	Хранение полной информации о контрагентах.
Товары	ID_Товара (PK), Наименование, Единица_измерения, Оптовая_цена, Розничная_цена, ID_Категории (FK)	Хранение справочной информации о готовой продукции.
Сотрудники	ID_Сотрудника (PK), ФИО, ID_Должности (FK), Телефон, Email	Учет персонала отдела сбыта.
Заказы (Сделки)	ID_Заказа (PK), Дата_заказа, ID_Покупателя (FK), ID_Менеджера (FK), Статус (Оформлен, Оплачен, Отгружен), Общая_сумма	Основной документ, фиксирующий факт продажи и его состояние.
Позиции_Заказа	ID_Позиции (PK), ID_Заказа (FK), ID_Товара (FK), Количество, Цена_единицы, Сумма_по_позиции	Детализация содержимого каждого заказа.
Отгрузки	ID_Отгрузки (PK), ID_Заказа (FK), Дата_отгрузки, Адрес_доставки, Статус_доставки	Учет фактической реализации и логистики.

Взаимосвязи между сущностями:

1. Покупатели ↔ Заказы: Связь типа «Один-ко-многим» (1:N). Один покупатель может оформить множество заказов.
2. Сотрудники ↔ Заказы: Связь типа «Один-ко-многим» (1:N). Один менеджер ведет множество заказов.
3. Заказы ↔ Позиции_Заказа: Связь типа «Один-ко-многим» (1:N). Один заказ состоит из множества позиций.
4. Товары ↔ Позиции_Заказа: Связь типа «Один-ко-многим» (1:N). Один товар может присутствовать во множестве позиций разных заказов.
5. Заказы ↔ Отгрузки: Связь типа «Один-ко-многим» (1:N) или «Один-к-одному» (1:1), в зависимости от того, может ли один заказ быть разбит на несколько отгрузок.

Логическая модель данных и структура таблиц

После нормализации концептуальная модель преобразуется в набор таблиц (отношений) с определенными ключами.

Пример структуры основной транзакционной таблицы Заказы:

Атрибут (Поле)	Тип данных	Описание	Ограничение
ID_Заказа	INTEGER	Уникальный идентификатор заказа	Первичный ключ (PK)
Дата_Заказа	DATE	Дата и время создания заказа	NOT NULL
ID_Покупателя	INTEGER	Ссылка на таблицу Покупатели	Внешний ключ (FK)
ID_Менеджера	INTEGER	Ссылка на таблицу Сотрудники	Внешний ключ (FK)
Статус	VARCHAR(50)	Текущее состояние заказа	CHECK (‘Оплачен’, ‘В обработке’ и т.д.)
Общая_Сумма	DECIMAL(10, 2)	Итоговая сумма по всем позициям

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

Обоснование выбора технологической платформы для реализации ИС

Выбор технологического стека, в особенности СУБД, является критическим этапом физического проектирования, определяющим надежность, масштабируемость и стоимость владения ИС.

Сравнительный анализ реляционных СУБД

Системы управления базами данных должны соответствовать ключевым требованиям: непротиворечивость данных, актуальность, многоаспектное использование, надежность и скорость доступа.

СУБД	Модель	Преимущества	Недостатки/Контекст использования
Microsoft Access	Реляционная	Простота, подходит для малых БД и учебных целей.	Низкая масштабируемость, не подходит для многопользовательской работы и больших объемов данных.
MySQL	��еляционная	Открытый исходный код, высокая скорость, распространенность.	Меньшая устойчивость к нагрузкам, чем у корпоративных систем.
Microsoft SQL Server	Реляционная	Высокая производительность, развитые инструменты, отличная интеграция с экосистемой MS.	Высокая стоимость лицензий для корпоративных решений.
PostgreSQL	Объектно-реляционная	Надежность, высокая отказоустойчивость, соответствие стандартам SQL:2023, открытый код.	Более сложная настройка по сравнению с MySQL.
Postgres Pro	Объектно-реляционная	Отечественный аналог PostgreSQL, входящий в Реестр российского ПО. Совместимость с российскими ОС (Astra Linux).	Требует специалистов для поддержки.

Обоснование выбора:
Для курсовой работы в учебных целях может быть выбран MS Access или MySQL из-за их простоты. Однако для реального корпоративного проекта, ориентированного на масштабируемость, многопользовательский доступ и, главное, на требования импортозамещения, оптимальным выбором является Postgres Pro. Эта СУБД сочетает в себе открытость, надежность корпоративного уровня (как PostgreSQL) и официальную поддержку отечественной инфраструктуры. Все современные СУБД поддерживают стандартный язык доступа к данным SQL, который непрерывно развивается. Актуальным международным стандартом является SQL:2023 (ISO/IEC 9075).

Интеграция с BPM/CRM-системами

Информационная система отдела сбыта редко существует в вакууме. В рамках крупного предприятия она должна рассматриваться как часть единого контура управления, который реализуется через BPM (Business Process Management) и CRM (Customer Relationship Management) системы.

• CRM-системы являются ключевыми инструментами для автоматизации процессов взаимодействия с клиентами (ведение клиентской базы, история сделок, воронка продаж).
• BPM-платформы (например, ELMA365, BPMSoft) позволяют автоматизировать сквозные бизнес-процессы, объединяя продажи, документооборот, сервис-деск и финансы.

Ключевое преимущество Low-code/No-code платформ:
Современные отечественные решения, такие как ELMA365 CRM+CX, BPMSoft и Directum, предлагают возможность быстрой реализации функционала ИС отдела сбыта на основе Low-code/No-code технологий. Это позволяет студенту-проектировщику сосредоточиться на логике бизнес-процессов и структуре данных, а не на низкоуровневом кодировании, обеспечивая при этом гибкость, масштаб и соответствие использованию российского ПО, что критически важно для государственных и крупных корпоративных заказчиков.

Экономическая эффективность и анализ рисков внедрения ИС

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

Количественная оценка преимуществ и эффективности

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

Показатель эффективности	Количественные данные / Ожидаемый эффект	Обоснование
Рост выручки	В среднем около 25% в первый год использования ИС.	Улучшение качества обслуживания и повышение лояльности клиентов.
Сокращение рутинного времени менеджеров	Снижение с 65% до 20–25% рабочего времени.	Автоматизация документооборота, сортировки писем, распределения задач. Высвобожденное время тратится на прямые продажи.
Экономия рабочего времени	До 15 часов в неделю на команду из пяти человек.	Использование ИИ-ассистентов для классификации писем и черновиков ответов. Эквивалентно высвобождению 7.5% общего фонда рабочего времени.
Срок окупаемости (ROI)	6–12 месяцев для процессов средней сложности.	Быстрый эффект за счет сокращения ошибок, потерь лидов и оптимизации запасов (через EOQ).
Снижение операционных ошибок	Значительное уменьшение ошибок, связанных с человеческим фактором.	Внедрение автоматических проверок целостности данных и устранение ручного переноса информации.

Внедрение ИС также улучшает способность системы сбыта быстро реагировать на внешние изменения, предоставляя точные отчеты по продажам, что способствует принятию более обоснованных стратегических решений.

Минимизация рисков и ограничений проекта

Любой ИТ-проект сопряжен с рисками, которые можно разделить на технические и управленческие.

1. Технические риски и стоимость ошибок

• Риск ошибок проектирования: Ошибки, допущенные на этапе концептуального проектирования (неправильно определены сущности или связи), наиболее критичны. Стоимость их исправления на поздних этапах (тестирование, сопровождение) может быть в 5–7 раз выше, чем если бы они были обнаружены на стадии анализа.
  • Минимизация: Использование строгого методологического подхода (ER-моделирование, нормализация до 3НФ) и активное вовлечение конечных пользователей (менеджеров сбыта) на стадии концептуального анализа.
• Риск неверного выбора СУБД: Выбор неадекватной СУБД (например, MS Access для крупного предприятия) приведет к проблемам с масштабируемостью и производительностью.
  • Минимизация: Использование корпоративных, масштабируемых решений (Postgres Pro, MS SQL Server) и тестирование производительности на эталонных нагрузках.

2. Управленческие и человеческие риски

• Риск саботажа и провала проекта: Высокий риск провала возникает, если сотрудники отдела сбыта не мотивированы использовать новую систему, поскольку это требует переобучения и изменения устоявшихся привычек. Саботаж также вероятен, если сотрудники воспринимают автоматизацию как инструмент тотального контроля или угрозу увольнения.
  • Минимизация: Прозрачное управление изменениями, обязательное обучение персонала, четкое объяснение, что автоматизация трансформирует задачи, а не ведет к увольнению. Проект должен вести руководитель с высоким авторитетом.
• Неправильный подход к автоматизации: Ошибка рассматривать BPM-систему как инструмент только для одного отдела.
  • Минимизация: ИС отдела сбыта должна проектироваться с учетом сквозных процессов, охватывающих взаимодействие с производством, складом и финансами, используя BPM-системы для объединения всех подразделений в единый контур.
• Ограничения ИИ и автоматизации: Важно помнить, что искусственный интеллект, который может быть интегрирован в ИС (для сортировки почты, формирования черновиков), пока не способен принимать нестандартные решения, выстраивать стратегию или вести сложные переговоры. Эти задачи остаются исключительно за человеком.

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

Заключение

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

В ходе работы была достигнута основная цель — разработана исчерпывающая методология создания ИС. Мы выполнили задачи по анализу предметной области, выявив ключевые бизнес-процессы (включая B2B-воронку продаж и необходимость расчета EOQ), а также спроектировали структуру базы данных, основанную на ER-моделировании и строгой нормализации.

Обоснованный выбор технологического стека, ориентированный на современные и отечественные СУБД (Postgres Pro) и Low-code BPM-платформы (ELMA365, BPMSoft), позволяет реализовать систему, соответствующую требованиям масштабируемости и импортозамещения. Экономическое обоснование, подкрепленное количественными данными (ожидаемый рост выручки до 25%, сокращение рутинного времени), подтверждает высокий потенциал окупаемости проекта.

Перспективы развития разработанной информационной системы включают:

1. Глубокую интеграцию с BI-инструментами для предиктивного анализа продаж и прогнозирования спроса.
2. Расширение функционала ИИ-ассистентов для автоматического формирования сложных коммерческих предложений.
3. Мобильную реализацию для обеспечения доступа менеджеров к данным в режиме реального времени.

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

1. Балдин, К. В. Информационные технологии в менеджменте : учебник. Москва : Академия, 2012. 288 с.
2. Дейт, К. Введение в системы баз данных: проектирование. Реализация и управление. Санкт-Петербург : БХВ-Петербург, 2004. 324 с.
3. Карпова, Т. С. Базы данных: модели, разработка, реализация : учебник. Санкт-Петербург : Питер, 2002. 303 с.
4. Корпоративный ИИ для автоматизации бизнес-процессов в 2025 году // Digital Report : [сайт]. [2025]. URL: digital.report/korporativnyy-ii-dlya-avtomatizatsii-biznes-protsessov-v-2025-godu (дата обращения: 29.10.2025).
5. Кошелев, В. Е. Access 2007. Эффективное использование. Москва : Бином-Пресс, 2009. 590 с.
6. Критерии выбора СУБД при создании информационных систем // CITForum.ru : [сайт]. URL: citforum.ru/consulting/articles/dbms_selection_criteria/ (дата обращения: 29.10.2025).
7. Кузин, А. В., Левонисова, С. В. Базы данных : учебное пособие. 2-е изд. Москва : Академия, 2008. 320 с.
8. Кузнецов, С. Д. Основы баз данных. 2-е изд. Москва : Интернет-Университет Информационных Технологий ; БИНОМ. Лаборатория знаний, 2007. 484 с.
9. Как автоматизировать отдел продаж: проблемы и пути решения // Блог компании i2crm : [сайт]. URL: i2crm.ru/blog/kak-avtomatizirovat-otdel-prodazh-problemy-i-puti-resheniya/ (дата обращения: 29.10.2025).
10. Как автоматизировать отдел продаж и какие сервисы в этом помогут // Timeweb : [сайт]. URL: timeweb.com/ru/community/articles/kak-avtomatizirovat-otdel-prodazh-i-kakie-servisy-v-etom-pomogut (дата обращения: 29.10.2025).
11. Малыхина, М. П. Базы данных: основы, проектирование, использование. 2-е изд., перераб. и доп. Санкт-Петербург : БХВ-Петербург, 2007. 528 с.
12. МЕТОДОЛОГИЯ ПРОЕКТИРОВАНИЯ И СОЗДАНИЯ БАЗ ДАННЫХ ДЛЯ СОВРЕМЕННОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ // Научные журналы Universum : [сайт]. URL: 7universum.com/ru/tech/archive/item/16666 (дата обращения: 29.10.2025).
13. Мэтью Мак-Дональд. Access 2007 Недостающее руководство. Санкт-Петербург : БХВ-Петербург, 2007. 784 с.
14. Проектирование баз данных. СУБД MicrosoftAccess : учебное пособие для вузов / Н. Н. Гринченко и др. Москва : Горячая линия-Телеком, 2004. 240 с.
15. Сергеев, А. В. Access 2007. Новые возможности. Санкт-Петербург : Питер, 2008. 176 с.
16. СУБД: что такое системы управления базами данных, виды, где используются, для чего нужны // DIS Group : [сайт]. URL: disgroup.ru/blog/chto-takoe-subd-i-dlya-chego-nuzhny-sistemy-upravleniya-bazami-dannyh (дата обращения: 29.10.2025).
17. Харитонова, И., Рудикова, Л. Microsoft Office Access 2007. Санкт-Петербург : БХВ-Петербург, 2008. 1280 с.
18. Хомоненко, А. Д., Цыганков, В. М., Мальцев, М. Г. Базы данных : учебник для высших учебных заведений. 6-е изд. Санкт-Петербург : КОРОНА принт, 2009. 736 с.
19. Что такое автоматизация бизнес-процессов и как ее внедрить // Тинькофф Бизнес : [сайт]. URL: tinkoff.ru/business/articles/avtomatizatsiya-biznes-processov/ (дата обращения: 29.10.2025).
20. Что такое ER-диаграмма и как ее создать? // Lucidchart : [сайт]. URL: lucidchart.com/pages/ru/chto-takoe-er-diagramma-i-kak-ee-sozdat (дата обращения: 29.10.2025).