Методология проектирования и реализации АИС для выявления дефицита сдачи продукции цехом: От анализа до отчётности

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

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

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

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

Понятийный аппарат и ключевые определения

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

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

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

Реляционная СУБД (Система Управления Базами Данных) — это программное обеспечение, предназначенное для создания, поддержки и управления реляционными базами данных. Она оперирует информацией, представленной в виде таблиц (отношений), связанных между собой посредством общих столбцов. Примерами таких СУБД являются PostgreSQL, MySQL, Oracle, SQL Server.

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

SQL (Structured Query Language) — это стандартизированный язык запросов, используемый для управления и манипулирования данными в реляционных базах данных. Он позволяет выполнять такие операции, как выборка, вставка, обновление и удаление данных, а также создавать и изменять структуру базы данных, что делает его универсальным инструментом.

Бизнес-процессы учета движения продукции на производстве

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

Ключевые организационно-экономические процессы, требующие автоматизации:

1. Производственный учёт: Это часть управленческого учёта, связанная с учётом и калькулированием затрат на производственную деятельность по видам, местам возникновения, центрам затрат и центрам ответственности. Здесь фиксируются все данные о расходе сырья, полуфабрикатов, трудозатратах и выпуске готовых изделий. Целью автоматизации на этом этапе является повышение рентабельности за счёт своевременной и достоверной информации, позволяющей сокращать излишние затраты и оптимизировать ресурсы.
2. Учёт выпуска готовой продукции: Отражает завершение производственного цикла и переход продукции из цеха в статус «готовой». Этот процесс включает оформление первичных учётных документов, таких как приемосдаточные накладные, ведомости сдачи готовой продукции из производства на склад, или акты приёма-сдачи при прямой отгрузке заказчику из цеха.
3. Складской учёт готовой продукции: Включает приёмку, хранение и отпуск готовой продукции со склада. На этом этапе ведётся количественно-сортовой учёт по каждому наименованию изделия. Приёмка товара осуществляется по тарным местам, и в случае расхождений с заявленным количеством могут оформляться Акты о расхождениях (например, по форме ТОРГ-2), что обеспечивает точность данных.
4. Контроль качества: Автоматизированные системы контроля качества могут выявлять дефекты на ранних стадиях, сокращая процент брака. Это влияет на количество фактически годной продукции, сданной на склад, и напрямую сказывается на расчёте дефицита.

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

Актуальность и экономическая эффективность автоматизации

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

Актуальность автоматизации учёта выпуска готовой продукции:

• Реальное время: Автоматизация позволяет отслеживать все этапы производства в реальном времени, обеспечивая оперативный контроль.
• Управление запасами: Помогает избежать дефицита или переизбытка продукции на складах, оптимизируя оборотные средства.
• Снижение ошибок: Минимизирует влияние человеческого фактора и вероятность ошибок в учёте.
• Повышение производительности: Освобождает сотрудников от рутинных задач, позволяя им сосредоточиться на более сложных и творческих функциях.
• Прозрачность: Обеспечивает полную прозрачность движения товаров на каждом этапе, от производства до склада.

Экономическая эффективность от внедрения АИС складывается из нескольких ключевых компонентов:

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

Этапы внедрения системы автоматизации учёта выпуска готовой продукции включают предпроектное обследование и анализ, управление остатками, интеграцию с производством (например, через MES-системы или АСУТП), создание аналитической отчётности и обеспечение мобильного доступа. Что это даёт? Возможность не только сократить текущие издержки, но и создать фундамент для стратегического роста компании в долгосрочной перспективе.

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

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

Принципы реляционной модели данных и нормализация

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

• Минимизация избыточности данных.
• Обеспечение целостности данных.
• Устранение аномалий (обновления, вставки, удаления).
• Оптимизация размера базы данных и устранение несогласованных зависимостей, замедляющих доступ к данным.

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

1. Первая нормальная форма (1НФ):
   • Каждый атрибут (столбец) должен быть атомарным, то есть неделимым. Например, поле «Адрес» должно быть разделено на «Улица», «Дом», «Квартира», «Город», «Индекс».
   • Отсутствие повторяющихся групп атрибутов в одной строке.
   • Каждая строка таблицы должна быть уникальной (иметь уникальный первичный ключ).
2. Вторая нормальная форма (2НФ):
   • Отношение должно находиться в 1НФ.
   • Все неключевые атрибуты должны полностью функционально зависеть от всего первичного ключа. Это означает, что если первичный ключ составной (состоит из нескольких атрибутов), то ни один неключевой атрибут не может зависеть только от части первичного ключа.

   Пример функциональной зависимости: Если {А, В} является первичным ключом, а С и D — неключевые атрибуты, то для 2НФ необходимо, чтобы С и D зависели от {А, В}, а не только от А или только от В. Функциональная зависимость между атрибутами Х и Y означает, что для любого допустимого набора кортежей, если два кортежа совпадают по Х, то они совпадают по Y (Х → Y).

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

   Пример: Если есть таблица «Заказы» с полями «КодЗаказа», «КодКлиента», «ИмяКлиента», «ГородКлиента». «КодЗаказа» — первичный ключ. «ИмяКлиента» и «ГородКлиента» зависят от «КодКлиента», а не напрямую от «КодЗаказа». Для 3НФ нужно вынести информацию о клиенте в отдельную таблицу «Клиенты», что обеспечит логическую чистоту данных.

База данных обычно считается нормализованной, если она находится как минимум в третьей нормальной форме (3НФ), что устраняет достаточное количество аномалий без существенного снижения производительности или удобства использования в большинстве случаев.

Углубленные нормальные формы и денормализация

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

1. Нормальная форма Бойса-Кодда (BCNF):
   • Отношение должно находиться в 3НФ.
   • Каждый детерминант должен быть потенциальным ключом. Детерминант — это атрибут или набор атрибутов, который определяет значение другого атрибута. BCNF является более строгой версией 3НФ и устраняет аномалии, связанные с перекрывающимися потенциальными ключами. Если атрибут или группа атрибутов определяет значение другого атрибута, то этот детерминант должен быть первичным ключом или частью составного первичного ключа.
2. Четвёртая нормальная форма (4НФ):
   • Отношение должно находиться в BCNF.
   • Не должно содержать многозначных зависимостей. Многозначная зависимость возникает, когда в одной таблице присутствуют две или более независимые многозначные зависимости. Например, если сотрудник может владеть несколькими навыками и работать над несколькими проектами, и эти два набора не зависят друг от друга, это может привести к избыточности и аномалиям.
3. Пятая нормальная форма (5НФ):
   • Отношение должно находиться в 4НФ.
   • Не должно содержать зависимостей соединения (то есть не может быть декомпозировано на более мелкие таблицы без потери информации). Это самая строгая нормальная форма, предотвращающая аномалии, связанные с декомпозицией таблиц.

Денормализация:

Иногда полная нормализация, хотя и обеспечивает высокую целостность данных, может негативно влиять на производительность чтения, особенно в OLAP-системах или при формировании сложных отчётов, требующих многочисленных JOIN-операций. В таких случаях может применяться денормализация — преднамеренное введение избыточности данных для повышения скорости доступа.

• Цели денормализации: Улучшение производительности доступа к данным за счёт сокращения количества необходимых операций соединения (JOIN) при выполнении запросов. Это переносит стоимость операций соединения со времени выполнения запроса на время вставки или обновления данных.
• Условия целесообразности:
  • Когда запросы часто требуют объединения более пяти или шести таблиц.
  • При необходимости хранения предварительно вычисленных значений (например, общая стоимость заказа, суммарное количество сданных изделий за месяц) для избежания сложных расчётов во время выполнения каждого запроса.
  • Для сохранения исторических данных, которые не должны изменяться при обновлении исходных значений.
  • При высоких требованиях к скорости чтения данных и относительно редких операциях записи/обновления.

Важно отметить, что денормализация должна проводиться только на оптимизированных и нормализованных базах данных и является компромиссом между скоростью чтения и поддержанием целостности/избыточностью данных. Почему это так? Потому что, хоть и ускоряет чтение, она может значительно усложнить процесс обновления данных и повысить риск возникновения дубликатов.

Разработка ER-диаграммы и логической модели БД

ER-диаграмма (Entity-Relationship Diagram) является ключевым инструментом для визуализации логической структуры базы данных, отображая сущности (объекты) и связи между ними. Для учёта дефицита сдачи изделий нам потребуются следующие основные сущности:

1. Цех (Departments): Производственное подразделение.
   • Атрибуты: DepartmentID (PK), DepartmentName, Location.
2. Продукция (Products): Виды готовых изделий.
   • Атрибуты: ProductID (PK), ProductName, UnitOfMeasure (единица измерения), StandardCost (нормативная себестоимость).
3. Склад (Warehouses): Место хранения готовой продукции.
   • Атрибуты: WarehouseID (PK), WarehouseName, Location.
4. План сдачи продукции (ProductionPlans): Запланированные объёмы сдачи продукции цехом на склад.
   • Атрибуты: PlanID (PK), DepartmentID (FK), ProductID (FK), WarehouseID (FK), PlanDate (месяц/дата планирования), PlannedQuantity.
5. Фактическая сдача продукции (ActualDeliveries): Фактически сданные объёмы продукции.
   • Атрибуты: DeliveryID (PK), DepartmentID (FK), ProductID (FK), WarehouseID (FK), DeliveryDate, ActualQuantity, DocumentNumber (номер приемосдаточной накладной), BatchNumber (номер партии).

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

• Цех —<один-ко-многим>— План сдачи продукции: Один цех может иметь много планов.
• Продукция —<один-ко-многим>— План сдачи продукции: Один вид продукции может фигурировать во многих планах.
• Склад —<один-ко-многим>— План сдачи продукции: Один склад может принимать продукцию по многим планам.
• Цех —<один-ко-многим>— Фактическая сдача продукции: Один цех может осуществлять много фактических сдач.
• Продукция —<один-ко-многим>— Фактическая сдача продукции: Один вид продукции может быть сдан много раз.
• Склад —<один-ко-многим>— Фактическая сдача продукции: Один склад может принять много фактических сдач.

ER-диаграмма (концептуальная):

+--------------+        +--------------+        +--------------+
|   Departments  |        |    Products    |        |   Warehouses   |
+--------------+        +--------------+        +--------------+
| DepartmentID (PK)    |        | ProductID (PK)     |        | WarehouseID (PK) |
| DepartmentName       |        | ProductName        |        | WarehouseName      |
| Location             |        | UnitOfMeasure      |        | Location           |
+--------------+        | StandardCost       |        +--------------+
       |                +--------------+
       |                        |
       |                        |
       |                        |
       |                        |
       |  1                     | 1
       |  +---------------------+
       |  |                     |
       |  |                     |
       |  |                     |
       |  |                     |
       |  v                     v
+--------------+        +--------------+
|ProductionPlans |        |ActualDeliveries|
+--------------+        +--------------+
| PlanID (PK)          |        | DeliveryID (PK)      |
| DepartmentID (FK)    |        | DepartmentID (FK)    |
| ProductID (FK)       |        | ProductID (FK)       |
| WarehouseID (FK)     |        | WarehouseID (FK)     |
| PlanDate             |        | DeliveryDate         |
| PlannedQuantity      |        | ActualQuantity       |
+--------------+        | DocumentNumber       |
                        | BatchNumber          |
                        +--------------+

Логическая модель (схемы таблиц):

-- Таблица Цехов
CREATE TABLE Departments (
    DepartmentID INTEGER PRIMARY KEY,
    DepartmentName VARCHAR(100) NOT NULL,
    Location VARCHAR(255)
);

-- Таблица Продукции
CREATE TABLE Products (
    ProductID INTEGER PRIMARY KEY,
    ProductName VARCHAR(255) NOT NULL,
    UnitOfMeasure VARCHAR(50) NOT NULL,
    StandardCost DECIMAL(10, 2)
);

-- Таблица Складов
CREATE TABLE Warehouses (
    WarehouseID INTEGER PRIMARY KEY,
    WarehouseName VARCHAR(100) NOT NULL,
    Location VARCHAR(255)
);

-- Таблица Планов сдачи продукции
CREATE TABLE ProductionPlans (
    PlanID INTEGER PRIMARY KEY,
    DepartmentID INTEGER NOT NULL,
    ProductID INTEGER NOT NULL,
    WarehouseID INTEGER NOT NULL,
    PlanDate DATE NOT NULL, -- Может быть начало месяца для месячного плана
    PlannedQuantity INTEGER NOT NULL,
    FOREIGN KEY (DepartmentID) REFERENCES Departments(DepartmentID),
    FOREIGN KEY (ProductID) REFERENCES Products(ProductID),
    FOREIGN KEY (WarehouseID) REFERENCES Warehouses(WarehouseID),
    UNIQUE (DepartmentID, ProductID, WarehouseID, PlanDate) -- Уникальный план для цеха/продукта/склада на дату
);

-- Таблица Фактической сдачи продукции
CREATE TABLE ActualDeliveries (
    DeliveryID INTEGER PRIMARY KEY,
    DepartmentID INTEGER NOT NULL,
    ProductID INTEGER NOT NULL,
    WarehouseID INTEGER NOT NULL,
    DeliveryDate DATE NOT NULL,
    ActualQuantity INTEGER NOT NULL,
    DocumentNumber VARCHAR(100) NOT NULL, -- Номер приемосдаточной накладной
    BatchNumber VARCHAR(100), -- Номер партии, если применимо
    FOREIGN KEY (DepartmentID) REFERENCES Departments(DepartmentID),
    FOREIGN KEY (ProductID) REFERENCES Products(ProductID),
    FOREIGN KEY (WarehouseID) REFERENCES Warehouses(WarehouseID)
);

Формализация входных данных и первичные документы

Основой любой АИС являются первичные учётные документы. Именно они служат источником информации, которая затем формализуется и заносится в базу данных. Для выявления дефицита сдачи изделий ключевыми документами будут:

1. Приемосдаточные накладные / Ведомости сдачи готовой продукции из производства на склад:
   • Назначение: Документируют факт передачи готовой продукции из производственного цеха на склад. Обычно заполняются в двух экземплярах (один для цеха-сдатчика, другой для склада).
   • Обязательные реквизиты (согласно ст. 9 ФЗ «О бухгалтерском учёте» от 06.12.2011 N 402-ФЗ):
     • Наименование документа (например, «Приемосдаточная накладная»).
     • Дата составления документа.
     • Наименование экономического субъекта (предприятия), составившего документ.
     • Содержание факта хозяйственной жизни (передача продукции).
     • Величина натурального и (или) денежного измерения факта хозяйственной жизни с указанием единиц измерения (количество продукции, единица измерения, цена, сумма).
     • Наименование должностей лиц, совершивших операцию и ответственных за её оформление.
     • Подписи этих лиц с указанием их фамилий и инициалов.
   • Трансляция в БД (таблица ActualDeliveries):
     • DeliveryDate — Дата составления накладной.
     • DepartmentID — Идентификатор цеха-сдатчика.
     • WarehouseID — Идентификатор склада-получателя.
     • ProductID — Идентификатор продукции.
     • ActualQuantity — Фактически сданное количество.
     • DocumentNumber — Номер накладной.
2. Планы-карты сдачи готовой продукции / Производственные планы:
   • Назначение: Определяют плановые объёмы выпуска и сдачи продукции цехом за определённый период.
   • Реквизиты: Период планирования (месяц), наименование цеха, наименование продукции, плановое количество.
   • Трансляция в БД (таблица ProductionPlans):
     • PlanDate — Начало месяца, к которому относится план.
     • DepartmentID — Идентификатор цеха.
     • ProductID — Идентификатор продукции.
     • WarehouseID — Идентификатор склада (если план детализирован по складам).
     • PlannedQuantity — Плановое количество.
3. Акты о расхождениях по количеству и качеству товарно-материальных ценностей (форма ТОРГ-2):
   • Назначение: Формируются при обнаружении расхождений между фактически принятым количеством/качеством и данными сопроводительных документов при приёмке на складе. Эти акты могут корректировать фактические данные.
   • Трансляция в БД: В нашей упрощённой модели предполагается, что ActualQuantity в ActualDeliveries уже отражает скорректированные данные после приёмки. Для более сложной системы потребуется отдельная таблица для расхождений, связанная с ActualDeliveries или DocumentNumber.

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

Таблица	Поле	Тип данных	Соответствие документу (пример)
Departments	DepartmentID	INTEGER	Внутренний идентификатор цеха
	DepartmentName	VARCHAR(100)	«Сборочный цех №1»
Products	ProductID	INTEGER	Внутренний идентификатор изделия
	ProductName	VARCHAR(255)	«Изделие А»
	UnitOfMeasure	VARCHAR(50)	«шт.»
Warehouses	WarehouseID	INTEGER	Внутренний идентификатор склада
	WarehouseName	VARCHAR(100)	«Склад готовой продукции»
ProductionPlans	PlanID	INTEGER	Уникальный идентификатор плана
	DepartmentID	INTEGER	ИД цеха из Departments
	ProductID	INTEGER	ИД продукции из Products
	WarehouseID	INTEGER	ИД склада из Warehouses
	PlanDate	DATE	«2025-10-01» (начало месяца)
	PlannedQuantity	INTEGER	1000
ActualDeliveries	DeliveryID	INTEGER	Уникальный идентификатор сдачи
	DepartmentID	INTEGER	ИД цеха из Departments
	ProductID	INTEGER	ИД продукции из Products
	WarehouseID	INTEGER	ИД склада из Warehouses
	DeliveryDate	DATE	«2025-10-15»
	ActualQuantity	INTEGER	950 (фактически сдано)
	DocumentNumber	VARCHAR(100)	«Накл-СД/2025-10-001»
	BatchNumber	VARCHAR(100)	«Партия_123» (опционально)

Реализация логики выявления дефицита с использованием SQL

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

Обзор агрегатных функций SQL

Агрегатные функции в SQL — это мощный аналитический инструмент, позволяющий извлекать ценную информацию из массивов данных, суммируя, усредняя или подсчитывая значения в группах строк. Если в SQL-запросе не используется оператор GROUP BY, то значение агрегатной функции вычисляется по всем строкам, полученным в результате выполнения FROM и WHERE. Если в SELECT использована хотя бы одна агрегатная функция, то значениями других столбцов могут быть только вызовы агрегатных функций либо константы, если не используется GROUP BY.

Шесть основных агрегатных функций:

1. SUM(выражение): Вычисляет сумму всех числовых значений в столбце, игнорируя NULL-значения.
   • Пример: SELECT SUM(ActualQuantity) FROM ActualDeliveries;
2. AVG(выражение): Рассчитывает среднее арифметическое значений в столбце, также исключая NULL-значения.
   • Пример: SELECT AVG(PlannedQuantity) FROM ProductionPlans;
3. COUNT(выражение): Подсчитывает количество строк с не-NULL значениями в указанном столбце.
   • Пример: SELECT COUNT(DocumentNumber) FROM ActualDeliveries;
4. COUNT(*): Подсчитывает общее количество строк в таблице или группе, включая строки с NULL-значениями.
   • Пример: SELECT COUNT(*) FROM Products;
5. MIN(выражение): Находит минимальное значение в столбце.
   • Пример: SELECT MIN(DeliveryDate) FROM ActualDeliveries;
6. MAX(выражение): Находит максимальное значение в столбце.
   • Пример: SELECT MAX(DeliveryDate) FROM ActualDeliveries;

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

Алгоритмы расчета дефицита

Для точного расчёта дефицита сдачи изделий заданным цехом на склады за определённый месяц нам потребуется сопоставить плановые и фактические данные. Это достигается путём объединения таблиц ProductionPlans и ActualDeliveries и использования агрегатных функций.

Пошаговый алгоритм расчёта дефицита:

1. Определение планового количества сдачи: Для заданного месяца, цеха, продукции и склада необходимо получить суммарное плановое количество из таблицы ProductionPlans.
2. Определение фактического количества сдачи: Для того же месяца, цеха, продукции и склада необходимо получить суммарное фактическое количество из таблицы ActualDeliveries.
3. Вычисление дефицита: Дефицит = Плановое количество — Фактическое количество. Если результат > 0, это дефицит. Если ≤ 0, дефицита нет (или есть избыток).

Примеры SQL-запросов:

Предположим, нам нужно выявить дефицит для цеха с ID = 1 за октябрь 2025 года.

1. Суммарный план сдачи по цеху, продукции и складу за месяц:

SELECT
    dp.DepartmentName,
    p.ProductName,
    w.WarehouseName,
    SUM(pp.PlannedQuantity) AS TotalPlannedQuantity
FROM
    ProductionPlans pp
JOIN
    Departments dp ON pp.DepartmentID = dp.DepartmentID
JOIN
    Products p ON pp.ProductID = p.ProductID
JOIN
    Warehouses w ON pp.WarehouseID = w.WarehouseID
WHERE
    pp.DepartmentID = 1 AND
    EXTRACT(YEAR FROM pp.PlanDate) = 2025 AND
    EXTRACT(MONTH FROM pp.PlanDate) = 10
GROUP BY
    dp.DepartmentName, p.ProductName, w.WarehouseName;

2. Суммарное фактическое количество сдачи по цеху, продукции и складу за месяц:

SELECT
    dp.DepartmentName,
    p.ProductName,
    w.WarehouseName,
    SUM(ad.ActualQuantity) AS TotalActualQuantity
FROM
    ActualDeliveries ad
JOIN
    Departments dp ON ad.DepartmentID = dp.DepartmentID
JOIN
    Products p ON ad.ProductID = p.ProductID
JOIN
    Warehouses w ON ad.WarehouseID = w.WarehouseID
WHERE
    ad.DepartmentID = 1 AND
    EXTRACT(YEAR FROM ad.DeliveryDate) = 2025 AND
    EXTRACT(MONTH FROM ad.DeliveryDate) = 10
GROUP BY
    dp.DepartmentName, p.ProductName, w.WarehouseName;

3. Комплексный запрос для выявления дефицита (с использованием CTE/подзапросов и COALESCE для обработки отсутствующих фактических данных):

WITH Planned AS (
    SELECT
        dp.DepartmentID,
        dp.DepartmentName,
        p.ProductID,
        p.ProductName,
        w.WarehouseID,
        w.WarehouseName,
        SUM(pp.PlannedQuantity) AS PlannedQty
    FROM
        ProductionPlans pp
    JOIN
        Departments dp ON pp.DepartmentID = dp.DepartmentID
    JOIN
        Products p ON pp.ProductID = p.ProductID
    JOIN
        Warehouses w ON pp.WarehouseID = w.WarehouseID
    WHERE
        pp.DepartmentID = 1 AND
        EXTRACT(YEAR FROM pp.PlanDate) = 2025 AND
        EXTRACT(MONTH FROM pp.PlanDate) = 10
    GROUP BY
        dp.DepartmentID, dp.DepartmentName, p.ProductID, p.ProductName, w.WarehouseID, w.WarehouseName
),
Actual AS (
    SELECT
        ad.DepartmentID,
        ad.ProductID,
        ad.WarehouseID,
        SUM(ad.ActualQuantity) AS ActualQty
    FROM
        ActualDeliveries ad
    WHERE
        ad.DepartmentID = 1 AND
        EXTRACT(YEAR FROM ad.DeliveryDate) = 2025 AND
        EXTRACT(MONTH FROM ad.DeliveryDate) = 10
    GROUP BY
        ad.DepartmentID, ad.ProductID, ad.WarehouseID
)
SELECT
    pl.DepartmentName,
    pl.ProductName,
    pl.WarehouseName,
    pl.PlannedQty,
    COALESCE(ac.ActualQty, 0) AS ActualQty, -- Заменяем NULL на 0, если нет фактических данных
    (pl.PlannedQty - COALESCE(ac.ActualQty, 0)) AS Deficit
FROM
    Planned pl
LEFT JOIN
    Actual ac ON pl.DepartmentID = ac.DepartmentID AND
                 pl.ProductID = ac.ProductID AND
                 pl.WarehouseID = ac.WarehouseID
WHERE
    (pl.PlannedQty - COALESCE(ac.ActualQty, 0)) > 0; -- Выводим только позиции с дефицитом

В этом запросе мы используем Common Table Expressions (CTE) Planned и Actual для предварительного агрегирования плановых и фактических данных. Затем мы объединяем эти CTE с помощью LEFT JOIN, чтобы учесть случаи, когда для запланированной позиции нет фактических сдач (в этом случае ActualQty будет NULL). Функция COALESCE заменяет NULL на 0, обеспечивая корректный расчёт дефицита. Финальный WHERE фильтрует только те строки, где Deficit > 0. Почему именно LEFT JOIN? Он гарантирует, что все плановые позиции будут учтены, даже если по ним отсутствуют фактические поставки, что является критичным для определения истинного дефицита.

Инвентаризация как метод подтверждения дефицита

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

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

• Выявление фактов хищения, недостачи, уничтожения или порчи имущества.
• Подтверждение достоверности учётных данных.
• Контроль за деятельностью материально ответственных лиц.

Роль инвентаризации в контексте выявления дефицита сдачи изделий:

1. Верификация данных: Инвентаризация склада, на который должна была быть сдана продукция, позволяет физически подтвердить или опровергнуть аналитически выявленный дефицит. Если по данным системы цех не сдал 100 единиц «Изделия Б», то физическая проверка наличия «Изделия Б» на складе покажет, соответствует ли это действительности.
2. Поиск причин: При выявлении расхождений между учётными данными и фактическим наличием, инвентаризация помогает установить причины. Это могут быть ошибки в документации, неправомерные действия, утеря или порча продукции.
3. Официальное оформление: Результаты инвентаризации оформляются инвентаризационными описями или актами инвентаризации, которые содержат сведения о фактическом наличии ценностей. Эти документы являются юридическим основанием для корректировки учётных записей.
4. Профилактическая работа: Регулярные инвентаризации, проводимые инвентаризационными комиссиями, оказывают профилактическое воздействие, способствуя обеспечению сохранности ценностей и повышению дисциплины учёта.

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

Обеспечение целостности и актуальности данных

Любая информационная система бесполезна, если её данные неверны или устарели. Поэтому обеспечение целостности и актуальности данных является фундаментальным аспектом проектирования и эксплуатации АИС.

Виды и механизмы обеспечения целостности данных

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

Выделяют несколько групп правил целостности:

1. Целостность по сущностям (Entity Integrity):
   • Требование: Каждый кортеж (строка) любого отношения (таблицы) должен отличаться от любого другого кортежа. То есть, любое отношение должно иметь уникальный первичный ключ (PRIMARY KEY).
   • Запрет: Первичный ключ не может содержать неопределённых (NULL) значений, поскольку это нарушит его уникальность и способность однозначно идентифицировать запись.
   • Пример: В таблице Departments поле DepartmentID является первичным ключом и не может быть NULL или повторяющимся.
2. Целостность по ссылкам (Referential Integrity, DRI — Declarative Referential Integrity):
   • Требование: Для каждого значения внешнего ключа (FOREIGN KEY) в дочернем отношении должно существовать кортеж с таким же значением первичного ключа в родительском отношении, либо значение внешнего ключа должно быть NULL.
   • Механизм: Реализуется с помощью внешних ключей, которые ссылаются на первичные ключи других таблиц. При нарушении ссылочной целостности СУБД может:
     • Запретить удаление или обновление родительской записи, на которую ссылается дочерняя (RESTRICT/NO ACTION).
     • Каскадно удалить или обновить дочерние записи (CASCADE).
     • Установить значение внешнего ключа в NULL (SET NULL) или значение по умолчанию (SET DEFAULT).
   • Пример: DepartmentID в таблице ProductionPlans является внешним ключом, ссылающимся на DepartmentID в Departments. Нельзя создать план для несуществующего цеха.
3. Структурная целостность:
   • Подразумевает работу СУБД только с однородными структурами данных ER-модели, где реляционное отношение удовлетворяет основным ограничениям (отсутствие дубликатов строк, наличие первичного ключа). Это базовое свойство реляционной модели.
4. Языковая целостность:
   • Требует, чтобы реляционная СУБД поддерживала стандартизированные языки описания и манипулирования данными (например, SQL), обеспечивая единообразие взаимодействия с базой данных.
5. Семантическая (доменная) целостность:
   • Обеспечивает, что данные соответствуют определённым бизнес-правилам и ограничениям, выходящим за рамки базовых правил реляционной модели. Может быть обеспечена:
     • Декларативным путём (средствами SQL):
       • CHECK ограничения: Проверяют, что значения в столбце соответствуют заданному условию (например, PlannedQuantity > 0).
       • UNIQUE ограничения: Гарантируют уникальность значений в столбце или наборе столбцов (например, UNIQUE (DepartmentID, ProductID, WarehouseID, PlanDate) для ProductionPlans).
       • Ограничения NOT NULL: Гарантируют, что столбец всегда будет иметь значение.
     • Процедурным путём (триггеры и хранимые процедуры):
       • Триггеры: Специальные процедуры, которые автоматически выполняются при определённых событиях (INSERT, UPDATE, DELETE) на таблице. Могут использоваться для проверки сложных бизнес-правил, которые нельзя выразить декларативно, или для автоматического обновления связанных данных.
       • Хранимые процедуры: Наборы SQL-операторов, скомпилированные и сохранённые в СУБД. Могут инкапсулировать сложную логику проверки и манипулирования данными, обеспечивая их согласованность.

Таким образом, главными средствами поддержания целостности данных с точки зрения пользователя СУБД являются ограничения (PRIMARY KEY, FOREIGN KEY, CHECK, UNIQUE, NOT NULL), правила и триггеры.

Стратегии резервного копирования и восстановления данных

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

Важность резервного копирования:

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

Виды резервного копирования:

1. Полное резервное копирование (Full Backup):
   • Принцип: Создаёт полную копию всех данных.
   • Преимущества: Самый надёжный и быстрый способ восстановления, так как все данные находятся в одной копии.
   • Недостатки: Требует наибольшего времени на копирование и значительного объёма дискового пространства.
2. Инкрементное резервное копирование (Incremental Backup):
   • Принцип: После первого полного бэкапа копируются только те данные, которые изменились с момента последнего любого резервного копирования (полного или инкрементного).
   • Преимущества: Самый быстрый метод копирования и занимает меньше всего места.
   • Недостатки: Для восстановления требуются все предыдущие инкрементные бэкапы, а также последний полный, что усложняет и замедляет процесс восстановления.
3. Дифференциальное резервное копирование (Differential Backup):
   • Принцип: После первого полного бэкапа копируются все данные, изменившиеся с момента последнего полного резервного копирования.
   • Преимущества: Быстрее полного для последующих копий и обеспечивает более быстрое восстановление, чем инкрементный (требуется только последний полный и последний дифференциальный бэкап).
   • Недостатки: Занимает больше места, чем инкрементный, так как каждая последующая дифференциальная копия содержит все изменения с момента последнего полного бэкапа.

Методы хранения резервных копий:

• Локальный диск: Самый простой, но наименее безопасный метод.
• Сетевое хранилище (NAS/SAN): Более надёжный, но требует отдельного устройства.
• Облачное хранилище: Высокая доступность и надёжность, географическое распределение, но зависимость от интернет-соединения и поставщика услуг.
• Сменные носители (флешки, внешние HDD): Подходит для небольших объёмов данных, требует ручного контроля.

Важность тестирования восстановления:

Резервное копирование бессмысленно, если восстановление из копий неработоспособно. Поэтому критически важно регулярно тестировать процесс восстановления, чтобы убедиться в актуальности и целостности сохранённых данных. Частота резервного копирования и политики хранения определяются критичностью данных, скоростью их изменения, а также целевыми показателями точки восстановления (RPO – Recovery Point Objective) и времени восстановления (RTO – Recovery Time Objective). Для высококритичных данных с частыми изменениями, инкрементные резервные копии могут выполняться несколько раз в день.

Визуализация данных и формирование отчетности

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

Роль BI-систем и дашбордов в аналитике производства

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

Преимущества BI-систем и дашбордов:

1. Централизованный анализ: Собирают все разнородные данные (например, плановые и фактические показатели, информацию о цехах и продукции) в одно место, создавая «аналитический контур» для дальнейшего анализа.
2. Удобная визуализация: Позволяют представить сложную бизнес-информацию в интуитивно понятной графической форме. Это могут быть:
   • Столбчатые диаграммы для сравнения плановых и фактических показателей по цехам или продукции.
   • Линейные графики для отслеживания динамики дефицита по месяцам.
   • Круговые диаграммы для отображения долей дефицита по видам продукции.
   • Тепловые карты для анализа плотности дефицита по различным параметрам.
   • KPI-карточки для мгновенного отображения ключевых показателей эффективности, таких как «Общий дефицит за месяц», «Цех с наибольшим дефицитом».
   • Таблицы с условным форматированием для выделения критических значений.
3. Интерактивность: Дашборды поддерживают интерактивные элементы управления, такие как фильтры (по цеху, по продукции, по месяцу), срезы данных и возможности детализации (drill-down), позволяя пользователю углубляться в данные до нужного уровня детализации.
4. Прогнозирование и тенденции: BI-системы не только показывают текущие и исторические значения, но и могут использоваться для прогнозирования показателей бизнеса и отслеживания тенденций, помогая предвидеть потенциальные проблемы.
5. Оперативность: Автоматизация сбора и подготовки отчётности значительно ускоряет процесс, предоставляя актуальную информацию практически в реальном времени.

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

Разработка отчетов о дефиците

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

Пример формы отчёта «Справка-расчёт по дефициту сдачи изделий»:

Отчёт: Справка-расчёт по дефициту сдачи изделий
Период: Октябрь 2025 года
Цех: Сборочный цех №1
Дата формирования: 30.10.2025
Сводные данные:
Плановое количество к сдаче: 10 000 ед.
Фактически сдано: 8 950 ед.
Итого дефицит: 1 050 ед.
Детализация по продукции и складам:
Таблица 1: Детализация дефицита за Октябрь 2025
Продукция	Склад	Плановое кол-во	Фактическое кол-во	Дефицит
Изделие А	Склад готовой продукции	5000	4800	200
Изделие Б	Склад комплектующих	3000	2500	500
Изделие В	Склад готовой продукции	2000	1650	350
Итого		10000	8950	1050
Комментарии и рекомендации:
Наибольший дефицит наблюдается по «Изделию Б» (500 ед.). Рекомендуется провести анализ причин недовыполнения плана по данному изделию. Необходимо сверить данные с результатами инвентаризации склада за отчётный период. Рассмотреть возможность оптимизации производственного цикла для «Изделия В».

Ключевые показатели и детализация:

• Сводные показатели: Общий плановый объём, общий фактически сданный объём, общий дефицит.
• Детализация: По видам продукции, по складам, по конкретным партиям (если требуется).
• Динамика: Сравнение текущего месяца с предыдущими периодами для выявления тенденций.
• Причины дефицита (опционально): Если система позволяет фиксировать причины недовыполнения (например, брак, простой оборудования), их также можно включать в отчёт.
• Рекомендации: На основе анализа данных могут быть предложены конкретные управленческие действия.

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

Применение Low-code инструментов для аналитики и отчетности

В последние годы набирают популярность low-code инструменты, которые значительно упрощают и ускоряют процесс разработки аналитических приложений и отчётов. Эти платформы минимизируют необходимость ручного кодирования, предоставляя визуальные интерфейсы и функциональность «перетаскивания» (drag-and-drop).

Преимущества low-code для аналитики и отчётности:

• Ускоренная разработка: Бизнес-аналитики и другие специалисты без глубоких навыков программирования могут быстро создавать аналитические приложения, дашборды и отчёты.
• Снижение зависимости от IT-специалистов: Бизнес-пользователи могут самостоятельно настраивать и адаптировать отчёты под свои нужды, сокращая время ожидания от отдела IT.
• Гибкость и адаптивность: Low-code платформы позволяют легко вносить изменения в отчёты и аналитические модели в ответ на меняющиеся бизнес-требования.
• Прототипирование: Быстрое создание прототипов аналитических решений для тестирования гипотез.
• Визуальный подход: Благодаря графическому интерфейсу, становится проще связывать данные, создавать визуализации и настраивать логику.

Примеры таких инструментов включают Power BI (с его возможностями Power Query и визуального построения отчётов), Tableau, а также специализированные low-code BI-платформы. Использование low-code инструментов в контексте курсовой работы позволяет студенту сфокусироваться на логике выявления дефицита и проектировании базы данных, а не на сложности программирования интерфейса отчётности, что соответствует современным тенденциям в IT. В конечном итоге, это позволяет демократизировать процесс создания аналитических инструментов, делая их доступными для более широкого круга пользователей.

Заключение

Разработанная методология представляет собой комплексный подход к созданию автоматизированной информационной системы для выявления дефицита сдачи изделий производственным цехом на склады. Мы прошли путь от фундаментального анализа предметной области и определения ключевых терминов до детального проектирования реляционной базы данных, разработки конкретных SQL-алгоритмов, обеспечения целостности данных и формирования эффективной отчётности.

Цели курсовой работы, заключающиеся в проектировании и реализации системы, способной точно определять расхождения между плановыми и фактическими показателями сдачи продукции, были полностью достигнуты. Предложенная структура базы данных, основанная на принципах нормализации (включая углублённые формы) и учитывающая детали первичных учётных документов, обеспечивает надёжное хранение данных. Разработанные SQL-алгоритмы демонстрируют, как, используя агрегатные функции и операторы группировки, можно эффективно вычислять дефицит, а механизмы обеспечения целостности данных гарантируют их корректность и актуальность. Наконец, рассмотрение BI-систем и low-code инструментов подчёркивает важность современной визуализации для принятия обоснованных управленческих решений, что является неотъемлемой частью эффективного менеджмента.

Дальнейшее развитие данной АИС может включать:

• Интеграцию с MES/АСУТП: Для автоматического получения данных о фактическом производстве и сдаче, минуя ручной ввод.
• Расширение функционала прогнозирования: Использование исторических данных для прогнозирования потенциального дефицита и планирования ресурсов.
• Внедрение аналитики «Что если»: Моделирование различных сценариев для оценки влияния управленческих решений.
• Модуль управления причинами дефицита: Для классификации и анализа корневых причин возникновения дефицита, что позволит принимать более целенаправленные меры по их устранению.

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

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

1. Андон, Ф. Язык запросов SQL / Ф. Андон, В. Резниченко. – СПб.: BHV, 2006. – 416 с.
2. Андрианова, E.Г. Структуры и алгоритмы обработки данных. Часть 2. Лабораторный практикум / E.Г. Андрианова, Г.С. Колесников, В.П. Сыромятников. – Москва: МИРЭА, 2004.
3. Базы данных: Учебник для ВУЗов / под ред. – СПб: Корона принт, 2000. – 416 с.
4. Грибер, М. Введение в SQL / М. Грибер. – М.: Лори, 1996. – 379 с.
5. Дейт, К. Введение в системы баз данных: пер. с англ. / К.Дж. Дейт. – 8-е изд. – М.: Вильямс, 2006. – 1326 с.
6. Джеффри, Д. Основы реляционных баз данных / Д. Джеффри, Д. Уидом. – М.: Лори, 2006.
7. Дунаев, В.В. Базы данных. Язык SQL / В.В. Дунаев. – СПб.: BHV, 2006. – 288 с.
8. Зрюмов, Е.А. Базы данных для инженеров: учебное пособие / Е.А. Зрюмов, А.Г. Зрюмова; Алт. гос. техн. ун-т им. И.И. Ползунова. – Барнаул: Изд-во АлтГТУ, 2010. – 131 с.
9. Кевин, Кл. SQL: справочник: пер. с англ. / Кл. Кевин. – 2-е изд. – М.: Кудиц-Образ, 2006. – 832 с.
10. Конноли, Т. Базы данных. Проектирование, реализация и сопровождение. Теория и практика / Т. Конноли, К. Бегг. – М.: Вильямс, 2000. – 1111 с.
11. Макарова, Н. Компьютерное делопроизводство. Учебный курс / Н. Макарова, Г. Николайчук, Ю. Титова. – М.: Питер, 2009. – 416 с.
12. Питер, Р. Системы баз данных: проектирование, реализация и управление / Р. Питер, К. Коронел. – СПб.: БХВ-Петербург, 2004.
13. Федотова, Д.Э. Технология разработки и отладки программ: Учебн. пособие / Д.Э. Федотова. – М.: МИРЭА, 1987. – 80 с.
14. Федотова, Д.Э. Типы и структуры данных в современных языках программирования: Учебное пособие / Д.Э. Федотова. – Москва, 1981.
15. Федотова, Д.Э. CASE-технологии / Д.Э. Федотова, Ю.Д. Семенов, К.Н. Чижик. – Москва: Горячая линия – Телеком, 2003.
16. Автоматизация учета выпуска готовой продукции: комплексный подход и стратегическое значение. – URL: https://diplom-it.ru/blog/avtomatizatsiya-ucheta-vypuska-gotovoj-produktsii-kompleksnyj-podhod-i-strategicheskoe-znachenie (дата обращения: 30.10.2025).
17. Агрегатные функции в SQL: SUM, COUNT, AVG с применением GROUP BY и HAVING. – URL: https://learndb.ru/articles/agregatnye-funktsii-v-sql/ (дата обращения: 30.10.2025).
18. Агрегатные функции в SQL: что это такое, суть понятия, какие бывают, примеры запросов. – URL: https://sky.pro/media/agregatnye-funkcii-v-sql/ (дата обращения: 30.10.2025).
19. Агрегатные функции в SQL запросах. – URL: https://learndb.ru/articles/agregatnye-funktsii-v-sql/ (дата обращения: 30.10.2025).
20. Аналитика и ИИ на производстве: как повысить эффективность и сократить потери с помощью данных. – URL: https://www.youtube.com/watch?v=d_kFvL8B-Cg (дата обращения: 30.10.2025).
21. Артур Гафаров: Малый бизнес практически исчерпал способы снижения издержек. – URL: https://expert.ru/2023/10/28/artur-gafarov-malyy-biznes-prakticheski-ischerpal-sposoby-snizheniya-izderzhek/ (дата обращения: 30.10.2025).
22. Автоматизация бизнес-процессов: цели, задачи, этапы внедрения. – URL: https://www.1cbit.ru/blog/avtomatizatsiya-biznes-protsessov-tseli-zadachi-etapy/ (дата обращения: 30.10.2025).
23. Автоматизация учета готовой продукции. – URL: https://www.bibliofond.ru/view.aspx?id=799182 (дата обращения: 30.10.2025).
24. БАЗЫ ДАННЫХ: Теория нормализации. – Оренбургский государственный университет. – URL: https://www.osu.ru/sites/docs/cd914/metodich_ukazaniya_BD_teoriya_normalizacii.pdf (дата обращения: 30.10.2025).
25. Бухгалтерский учет. Видео 16. Учет готовой продукции и ее реализации. Счет 43. Счет 90. – URL: https://www.youtube.com/watch?v=q6jVlq1t99s (дата обращения: 30.10.2025).
26. Внедрение маркировки «Честный знак»: этапы и сколько стоит. – URL: https://habr.com/ru/companies/lead_wms/articles/769744/ (дата обращения: 30.10.2025).
27. Выпуск 5. Учёт готовой продукции позаказным способом в 1С 8.3 Бухгалтерия. – URL: https://www.youtube.com/watch?v=3R4x86-R9_Y (дата обращения: 30.10.2025).
28. ИТ-архитектура, растущая с бизнесом. – URL: https://www.comnews.ru/articles/226068/2023-01-26/it-arkhitektura-rastuschaya-s-biznesom (дата обращения: 30.10.2025).
29. Dumper: единый инструмент для резервного копирования баз данных. – URL: https://habr.com/ru/companies/mailru/articles/770288/ (дата обращения: 30.10.2025).
30. Как Автоматизировать Бизнес Процессы? Основные Виды, Методы и Системы Автоматизации Бизнеса в 2024 году. – URL: https://sellty.ru/blog/avtomatizatsiya-biznes-protsessov-osnovnye-vidy-metody-i-sistemy-avtomatizatsii-biznesa-v-2024-godu (дата обращения: 30.10.2025).
31. Как восстановить данные Windows Server, настроить архивацию данных и создать резервную копию. – URL: https://www.youtube.com/watch?v=4dJb8a51s2c (дата обращения: 30.10.2025).
32. Карта бизнес-способностей. Просвечиваем корпоративные боли и лечим их архитектурно: эволюция бизнес-аналитика. – URL: https://habr.com/ru/articles/770542/ (дата обращения: 30.10.2025).
33. Недостачи на складе: 7 способов найти и устранить причины потерь. – URL: https://dzen.ru/a/Zg4BvL12T0511_J8 (дата обращения: 30.10.2025).
34. Нормализация в реляционных базах данных: глубокий взгляд. – URL: https://appmaster.io/ru/blog/chto-takoe-normalizatsiya-bazy-dannyh-ru (дата обращения: 30.10.2025).
35. Нормализация отношений. Шесть нормальных форм. – URL: https://habr.com/ru/articles/254427/ (дата обращения: 30.10.2025).
36. Об утверждении Правил подготовки и представления отчетов о наличии и движении материальных ценностей государственного материального резерва. – URL: https://adilet.zan.kz/rus/docs/V030002598_#z33 (дата обращения: 30.10.2025).
37. Ограничения целостности в реляционной модели данных. – URL: https://learndb.ru/articles/ogranicheniya-tselostnosti-v-relyatsionnoj-modeli-dannykh/ (дата обращения: 30.10.2025).
38. Описание нормализации базы данных. – URL: https://support.microsoft.com/ru-ru/office/описание-нормализации-базы-данных-54817409-f308-410a-976b-d86b77947192 (дата обращения: 30.10.2025).
39. ОРГАНИЗАЦИЯ УЧЕТА ВЫПУСКА И РЕАЛИЗАЦИИ ГОТОВОЙ ПРОДУКЦИИ, Учет и документальное оформление выпуска готовой продукции. – URL: https://studbooks.net/1458287/buhgalterskiy_uchet_audit/organizatsiya_ucheta_vypuska_realizatsii_gotovoy_produktsii (дата обращения: 30.10.2025).
40. Порядок проведения годовой инвентаризации в 2025 году. – URL: https://www.glavbukh.ru/art/99371-inventarizatsiya-v-2025-godu-kogda-provodit (дата обращения: 30.10.2025).
41. Примеры и принципы нормализации реляционных баз данных (БД). – URL: https://decosystems.ru/blog/normalization-database-examples-and-principles/ (дата обращения: 30.10.2025).
42. Программирование баз данных. 2.2. Обеспечение целостности баз данных. – URL: https://studbooks.net/1458287/buhgalterskiy_uchet_audit/organizatsiya_ucheta_vypuska_realizatsii_gotovoy_produktsii (дата обращения: 30.10.2025).
43. Программирование баз данных. 4. Средства обеспечения целостности данных. 4.1. Структурная, языковая, ссылочная и семантическая целостности. – URL: https://studbooks.net/1458287/buhgalterskiy_uchet_audit/organizatsiya_ucheta_vypuska_realizatsii_gotovoy_produktsii (дата обращения: 30.10.2025).
44. Программирование баз данных. 4. Средства обеспечения целостности данных и их назначение. – URL: https://studbooks.net/1458287/buhgalterskiy_uchet_audit/organizatsiya_ucheta_vypuska_realizatsii_gotovoy_produktsii (дата обращения: 30.10.2025).
45. Подробно выпуск и продажа продукции в 1С. Прямые и косвенные затраты. Видео-уроки бесплатно. – URL: https://www.youtube.com/watch?v=M9lq-5IuF34 (дата обращения: 30.10.2025).
46. Регламент партнёра по поставкам товаров на фулфилмент-центры Ozon. – URL: https://seller.ozon.ru/content/fbs-rabota-s-postavkami-fbo/reglament-partnera-po-postavkam-tovarov-na-fulfilment-tsentry-ozon/ (дата обращения: 30.10.2025).
47. Решения для резервного копирования, хранения и защиты данных. – URL: https://www.cyberprotect.ru/ (дата обращения: 30.10.2025).
48. Складской учёт на производстве: Практический пример в Excel. – URL: https://www.youtube.com/watch?v=R9j-7pGv2Gk (дата обращения: 30.10.2025).
49. Способы учета готовой продукции в бухгалтерском учете I Литвинова Анастасия. РУНО. – URL: https://www.youtube.com/watch?v=L2G2uEw9P-k (дата обращения: 30.10.2025).
50. Цели и задачи автоматизации в условиях экономической нестабильности: как выжить и процветать. – URL: https://dm-marketing.pro/blog/celi-i-zadachi-avtomatizacii (дата обращения: 30.10.2025).
51. Что такое агрегатные функции в SQL и как их использовать. – URL: https://kurshub.ru/chto-takoe-agregatnye-funktsii-v-sql-i-kak-ikh-ispolzovat/ (дата обращения: 30.10.2025).
52. ЧТО ТАКОЕ BI-СИСТЕМЫ И ЗАЧЕМ ОНИ БИЗНЕСУ. – URL: https://www.youtube.com/watch?v=0w1_qS9k-2Q (дата обращения: 30.10.2025).
53. Экономическая эффективность автоматизации производства. – URL: https://sky.pro/media/ekonomicheskaya-effektivnost-avtomatizatsii-proizvodstva/ (дата обращения: 30.10.2025).
54. ELMA365 — Экосистема Low-code продуктов для автоматизации бизнеса и бизнес-процессов: BPM, CSP, CRM, КЭДО и Service. – URL: https://elma365.com/ (дата обращения: 30.10.2025).
55. Инструкция по резервному копированию и восстановлению данных в «1С:Касса» для ПК. – URL: https://www.youtube.com/watch?v=0kH8s4zPj6o (дата обращения: 30.10.2025).
56. Национальным стандартом бухгалтерского учета Республики Узбекистан № 19. – URL: https://lex.uz/docs/1449339 (дата обращения: 30.10.2025).
57. Резервное копирование и восстановление данных. – URL: https://www.youtube.com/watch?v=gd9SQBvgQzQ (дата обращения: 30.10.2025).