Проектирование и реализация информационной базы данных системы сбыта предприятия с использованием MS Access: Методологический подход

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

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

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

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

1.1. Основные понятия и определения реляционных баз данных

В 1970 году британский учёный Эдгар Фрэнк «Тед» Кодд, работавший в IBM, опубликовал свою революционную статью «A Relational Model of Data for Large Shared Data Banks». Эта работа заложила основы нового подхода к организации данных, который впоследствии стал доминирующим в мире информационных технологий. Так родилась реляционная база данных (РБД) — тип баз данных, где информация организована в виде связанных таблиц, или, как их называют в теории, отношений.

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

1. Сущности (Entity): Это реальные или абстрактные объекты предметной области, информация о которых должна храниться в базе данных. Например, в системе сбыта сущностями могут быть «Клиент», «Товар», «Заказ». Каждая сущность в реляционной модели соответствует таблице.
2. Атрибуты (Attribute): Это характеристики сущностей, описывающие их свойства. Каждый столбец в таблице представляет собой атрибут. Например, для сущности «Клиент» атрибутами будут «ФИО», «Адрес», «Телефон».
3. Связи (Relationship): Это логические отношения между сущностями. Именно связи позволяют объединять данные из разных таблиц для получения полной картины. Различают три основных типа связей:
   • Один-к-одному (1:1): Каждой записи в одной таблице соответствует не более одной записи в другой таблице. Этот тип связи встречается редко и часто указывает на то, что данные можно объединить в одну таблицу, но может быть полезен для разделения очень больших таблиц или для обеспечения безопасности.
   • Один-ко-многим (1:N): Каждой записи в одной таблице может соответствовать множество записей в другой таблице, но каждая запись во второй таблице соответствует только одной записи в первой. Это наиболее распространённый тип связи (например, один клиент может сделать много заказов, но каждый заказ принадлежит только одному клиенту).
   • Многие-ко-многим (N:M): Каждой записи в одной таблице может соответствовать множество записей в другой таблице, и наоборот. Этот тип связи напрямую не реализуется в реляционной модели, а разбивается на две связи «один-ко-многим» через создание промежуточной (ассоциативной) таблицы. Например, один товар может быть в нескольких заказах, и один заказ может содержать много товаров. Промежуточная таблица «Заказ-Товар» свяжет их.

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

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

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

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

1.2. Этапы и методологии проектирования баз данных

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

1. Концептуальное (инфологическое) проектирование. Это самый первый и наиболее абстрактный этап. Его главная задача — понять, что нужно хранить в базе данных, не привязываясь к конкретным технологиям или программному обеспечению. На этом этапе проводится глубокое изучение и описание предметной области (например, системы сбыта). Разработчик выявляет:
   • Сущности: Ключевые объекты или понятия, о которых нужно хранить информацию (например, «Клиент», «Товар», «Заказ»).
   • Атрибуты: Характеристики этих сущностей (например, для «Клиента» — «ФИО», «Адрес», «Телефон»).
   • Связи: Взаимоотношения между сущностями (например, «один клиент может оформить несколько заказов»).

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

2. Логическое проектирование. На этом этапе концептуальная модель преобразуется в логическую модель данных, которая уже учитывает особенности выбранной модели данных (в нашем случае — реляционной), но всё ещё независима от конкретной СУБД. Сущности ER-диаграммы превращаются в таблицы, атрибуты — в поля этих таблиц, а связи — в отношения между таблицами, реализуемые с помощью первичных и внешних ключей. Ключевой задачей логического проектирования является нормализация данных. Это процесс организации структуры таблиц для уменьшения избыточности и улучшения целостности данных. Подробно о нормализации мы поговорим позже, но на этом этапе закладываются основы для создания эффективной и надёжной реляционной схемы. Цели этого этапа: возможность получения данных по всем необходимым запросам и дальнейшее сокращение избыточности и дублирования.
3. Физическое проектирование. Это самый конкретный этап, на котором логическая модель преобразуется в реальную структуру базы данных, адаптированную под выбранную СУБД (например, MS Access, MySQL, PostgreSQL, Oracle). Здесь определяются:
   • Типы данных: Для каждого поля таблицы выбирается конкретный тип данных, поддерживаемый СУБД (например, «Текст», «Число», «Дата/время»).
   • Индексы: Создаются для ускорения поиска и сортировки данных.
   • Ограничения целостности: Устанавливаются правила для обеспечения корректности данных (например, обязательность заполнения поля, уникальность значений).
   • Физическое размещение данных: Определяются параметры хранения данных на диске.

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

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

• ERwin (Logic Works): Мощный инструмент для комплексного моделирования данных, поддерживающий как концептуальное, так и логическое и физическое проектирование.
• Open ModelSphere: Бесплатное кроссплатформенное CASE-средство, позволяющее создавать ER-диаграммы и генерировать SQL-скрипты.
• PowerDesigner (Sybase): Комплексное решение для архитектуры предприятия, поддерживающее широкий спектр моделей, включая модели данных, процессов и приложений.

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

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

Глава 2. Анализ предметной области и инфологическое проектирование системы сбыта

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

2.1. Анализ предметной области «Система сбыта предприятия»

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

Процесс анализа включает несколько ключевых шагов:

1. Выявление основных бизнес-процессов: Необходимо определить, как происходит весь цикл сбыта, начиная от поступления товара на склад и заканчивая отгрузкой клиенту и выставлением счёта. Типичные процессы включают:
   • Управление клиентами (регистрация, изменение данных)
   • Управление товарами (поступление, наличие, характеристики)
   • Обработка заказов (создание, изменение, отмена, отгрузка)
   • Управление поставками (закупки у поставщиков)
   • Выставление счетов и контроль оплаты
   • Формирование отчётности
2. Определение информационных потоков: Как информация перемещается между отделами и сотрудниками? Какие документы создаются? Кто инициирует действия? Например, отдел продаж создает заказ, склад комплектует, бухгалтерия выставляет счёт.
3. Идентификация ключевых бизнес-элементов: На этом этапе выделяются основные сущности, которые являются центральными для системы сбыта.
   • Клиенты: Юридические или физические лица, приобретающие товары/услуги.
   • Товары/Услуги: Предметы или услуги, предлагаемые к продаже.
   • Заказы: Документы, фиксирующие намерение клиента приобрести товар.
   • Поставщики: Компании, поставляющие товары предприятию.
   • Сотрудники: Персонал, участвующий в процессах сбыта (менеджеры, кладовщики).
   • Счета/Накладные: Финансовые документы.
   • Складские остатки: Информация о наличии товаров на складе.

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

• Хранить детальную информацию о каждом клиенте (ФИО/Название, адрес, контакты, история покупок).
• Вести учёт товаров с указанием характеристик (название, артикул, цена, описание, количество на складе).
• Регистрировать и отслеживать заказы клиентов, включая состав заказа, статус (принят, отгружен, оплачен), даты.
• Управлять информацией о поставщиках и закупках.
• Поддерживать учёт сотрудников и их роли.
• Формировать счета и накладные на основе заказов.
• Предоставлять актуальные данные о складских остатках.
• Генерировать различные отчёты для анализа (например, по продажам, задолженностям, популярности товаров).

Далее, для каждой выявленной сущности определяются её атрибуты — конкретные свойства, которые необходимо хранить.

Сущность	Атрибуты
Клиент	КодКлиента (первичный ключ), ФИО/Название, Адрес, Телефон, Email, ИНН, КПП, БанковскиеРеквизиты, ДатаРегистрации
Товар	КодТовара (первичный ключ), НазваниеТовара, Артикул, ЕдиницаИзмерения, ЦенаЗакупки, ЦенаПродажи, Описание, КодПоставщика (внешний ключ)
Заказ	НомерЗаказа (первичный ключ), КодКлиента (внешний ключ), КодСотрудника (внешний ключ), ДатаЗаказа, ДатаОтгрузки, СтатусЗаказа (например, «Новый», «В обработке», «Отгружен», «Отменен»), СуммаЗаказа
Сотрудник	КодСотрудника (первичный ключ), ФИО, Должность, Телефон, Email
Поставщик	КодПоставщика (первичный ключ), НазваниеПоставщика, КонтактноеЛицо, Телефон, Адрес, Email
ДеталиЗаказа	КодДеталиЗаказа (первичный ключ), НомерЗаказа (внешний ключ), КодТовара (внешний ключ), Количество, ЦенаНаМоментЗаказа
Счёт	НомерСчёта (первичный ключ), НомерЗаказа (внешний ключ), ДатаВыставления, ДатаОплаты, СуммаСчёта, СтатусОплаты (например, «Оплачен», «Не оплачен», «Частично оплачен»)

Наконец, выявляются типы связей между сущностями, исходя из бизнес-логики:

• Клиент (1) — Заказ (N): Один клиент может сделать множество заказов.
• Сотрудник (1) — Заказ (N): Один сотрудник может оформить множество заказов.
• Поставщик (1) — Товар (N): Один поставщик может поставлять множество товаров.
• Заказ (N) — Товар (M): Один заказ может содержать множество товаров, и один товар может быть в множестве заказов. Это классический пример связи «многие-ко-многим», которая будет реализована через промежуточную сущность ДеталиЗаказа.
• Заказ (1) — Счёт (N): Один заказ может быть связан с несколькими счетами (например, предоплата, доплата, или несколько накладных по одному заказу). Или, если принято, один заказ имеет один счёт (1:1).

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

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

2.2. Построение инфологической модели данных (ER-диаграмма)

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

Правила построения ER-модели:

1. Сущности (Entity): Представляются прямоугольниками и обозначают объекты или понятия, о которых необходимо хранить информацию. Имя сущности пишется внутри прямоугольника.
2. Атрибуты (Attribute): Представляются овалами или эллипсами и связаны с сущностями линиями. Атрибуты описывают характеристики сущности.
   • Ключевой атрибут: Подчеркивается и служит уникальным идентификатором сущности (первичный ключ). Например, КодКлиента.
   • Составной атрибут: Может быть разделён на более мелкие атрибуты (например, «Адрес» может состоять из «Улица», «Дом», «Квартира»).
   • Многозначный атрибут: Может иметь несколько значений для одной сущности (например, «Телефон», если у клиента несколько номеров). В реляционной модели такие атрибуты обычно выносятся в отдельные таблицы.
3. Связи (Relationship): Представляются ромбами и связывают две или более сущности, описывая их взаимодействие. Имя связи пишется внутри ромба. Каждая связь имеет мощность (кардинальность), которая указывает на количество экземпляров одной сущности, связанных с экземплярами другой сущности. Мощность обозначается числами и символами на концах линии связи:
   • 1:1 (один-к-одному): Один экземпляр сущности X связан только с одним экземпляром сущности Y.
   • 1:N (один-ко-многим): Один экземпляр сущности X связан со многими экземплярами сущности Y, но один экземпляр Y связан только с одним экземпляром X.
   • N:M (многие-ко-многим): Один экземпляр сущности X связан со многими экземплярами сущности Y, и наоборот. В реляционной модели такая связь разрешается путём создания промежуточной сущности (ассоциативной таблицы).

Пример ER-диаграммы для системы сбыта:

Представим упрощенную ER-диаграмму для нашей системы сбыта, основываясь на сущностях и связях, выявленных в предыдущем разделе.

erDiagram
    Клиент {
        INT <u>КодКлиента</u>
        VARCHAR ФИО_Название
        VARCHAR Адрес
        VARCHAR Телефон
        VARCHAR Email
        VARCHAR ИНН
        VARCHAR КПП
        VARCHAR БанковскиеРеквизиты
        DATE ДатаРегистрации
    }
    Товар {
        INT <u>КодТовара</u>
        VARCHAR НазваниеТовара
        VARCHAR Артикул
        VARCHAR ЕдиницаИзмерения
        DECIMAL ЦенаЗакупки
        DECIMAL ЦенаПродажи
        VARCHAR Описание
        INT КодПоставщика FK
    }
    Заказ {
        INT <u>НомерЗаказа</u>
        INT КодКлиента FK
        INT КодСотрудника FK
        DATE ДатаЗаказа
        DATE ДатаОтгрузки
        VARCHAR СтатусЗаказа
        DECIMAL СуммаЗаказа
    }
    Сотрудник {
        INT <u>КодСотрудника</u>
        VARCHAR ФИО
        VARCHAR Должность
        VARCHAR Телефон
        VARCHAR Email
    }
    Поставщик {
        INT <u>КодПоставщика</u>
        VARCHAR НазваниеПоставщика
        VARCHAR КонтактноеЛицо
        VARCHAR Телефон
        VARCHAR Адрес
        VARCHAR Email
    }
    ДеталиЗаказа {
        INT <u>КодДеталиЗаказа</u>
        INT НомерЗаказа FK
        INT КодТовара FK
        INT Количество
        DECIMAL ЦенаНаМоментЗаказа
    }
    Счёт {
        INT <u>НомерСчёта</u>
        INT НомерЗаказа FK
        DATE ДатаВыставления
        DATE ДатаОплаты
        DECIMAL СуммаСчёта
        VARCHAR СтатусОплаты
    }

    Клиент ||--o{ Заказ : "делает"
    Сотрудник ||--o{ Заказ : "обрабатывает"
    Поставщик ||--o{ Товар : "поставляет"
    Заказ }|--o{ ДеталиЗаказа : "содержит"
    Товар }|--o{ ДеталиЗаказа : "входит_в"
    Заказ ||--o{ Счёт : "генерирует"

Пояснения к диаграмме:

• Каждый прямоугольник представляет собой сущность.
• Подчеркнутые атрибуты являются первичными ключами.
• Атрибуты с пометкой FK являются внешними ключами, устанавливающими связи.
• Символы на линиях связей обозначают кардинальность:
  • ||--o{: Один-ко-многим (одна сущность слева, много справа, причем «много» может быть 0).
  • }|--o{: Обозначает, что сущность справа является частью связи «многие-ко-многим» (ассоциативная сущность).

Например, связь Клиент ||--o{ Заказ означает, что один клиент может сделать множество заказов. Связь Заказ }|--o{ ДеталиЗаказа и Товар }|--o{ ДеталиЗаказа показывает, что сущность «ДеталиЗаказа» разрешает связь «многие-ко-многим» между «Заказом» и «Товаром».

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

Глава 3. Логическое и физическое проектирование базы данных в MS Access

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

3.1. Логическое проектирование: преобразование ER-модели в реляционную схему

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

Правила преобразования ER-модели в реляционную схему:

1. Каждая сущность ER-модели становится отдельной таблицей. Имя таблицы должно отражать название сущности.
   • Пример: Сущность «Клиент» превращается в таблицу Клиенты.
2. Каждый атрибут сущности становится полем (столбцом) в соответствующей таблице.
   • Пример: Атрибуты сущности «Клиент» (КодКлиента, ФИО_Название, Адрес и т.д.) становятся полями в таблице Клиенты.
3. Ключевой атрибут сущности становится первичным ключом (Primary Key) таблицы. Первичный ключ уникально идентифицирует каждую запись в таблице.
   • Пример: КодКлиента из сущности «Клиент» становится первичным ключом КодКлиента в таблице Клиенты.
4. Реализация связей между таблицами с использованием первичных и внешних ключей (Foreign Key).
   • Связи «один-к-одному» (1:1): Обычно реализуются путём включения первичного ключа одной таблицы в качестве внешнего ключа в другую таблицу. Часто такие сущности объединяются в одну таблицу, если нет веских причин их разделять.
   • Связи «один-ко-многим» (1:N): Реализуются путём включения первичного ключа «одиночной» таблицы (со стороны «один») в качестве внешнего ключа в «множественную» таблицу (со стороны «многие»). Внешний ключ в «множественной» таблице будет ссылаться на первичный ключ «одиночной».
     • Пример: Связь «Клиент (1) — Заказ (N)» означает, что первичный ключ КодКлиента из таблицы Клиенты будет добавлен как внешний ключ КодКлиента в таблицу Заказы.
   • Связи «многие-ко-многим» (N:M): Это самый сложный случай. Они разрешаются путём создания новой, промежуточной (или ассоциативной) таблицы. Эта таблица будет содержать два внешних ключа, которые являются первичными ключами двух связанных таблиц. Часто эти два внешних ключа вместе образуют составной первичный ключ новой таблицы.
     • Пример: Связь «Заказ (N) — Товар (M)» разрешается созданием таблицы ДеталиЗаказа. В эту таблицу будут включены внешние ключи НомерЗаказа (ссылающийся на Заказы) и КодТовара (ссылающийся на Товары). Составной первичный ключ этой таблицы может быть (НомерЗаказа, КодТовара), или же можно добавить собственный первичный ключ КодДеталиЗаказа.

Предварительная структура таблиц для системы сбыта:

Основываясь на ER-диаграмме и правилах преобразования, получим следующую предварительную структуру реляционных таблиц (без применения нормализации выше 1НФ):

1. Клиенты
   • КодКлиента (Primary Key, Целое число)
   • ФИО_Название (Текст)
   • Адрес (Текст)
   • Телефон (Текст)
   • Email (Текст)
   • ИНН (Текст)
   • КПП (Текст)
   • БанковскиеРеквизиты (Текст)
   • ДатаРегистрации (Дата/время)
2. Товары
   • КодТовара (Primary Key, Целое число)
   • НазваниеТовара (Текст)
   • Артикул (Текст)
   • ЕдиницаИзмерения (Текст)
   • ЦенаЗакупки (Денежный)
   • ЦенаПродажи (Денежный)
   • Описание (Длинный текст)
   • КодПоставщика (Foreign Key, Целое число)
3. Заказы
   • НомерЗаказа (Primary Key, Целое число)
   • КодКлиента (Foreign Key, Целое число)
   • КодСотрудника (Foreign Key, Целое число)
   • ДатаЗаказа (Дата/время)
   • ДатаОтгрузки (Дата/время)
   • СтатусЗаказа (Текст)
   • СуммаЗаказа (Денежный)
4. Сотрудники
   • КодСотрудника (Primary Key, Целое число)
   • ФИО (Текст)
   • Должность (Текст)
   • Телефон (Текст)
   • Email (Текст)
5. Поставщики
   • КодПоставщика (Primary Key, Целое число)
   • НазваниеПоставщика (Текст)
   • КонтактноеЛицо (Текст)
   • Телефон (Текст)
   • Адрес (Текст)
   • Email (Текст)
6. ДеталиЗаказа (Ассоциативная таблица для связи N:M между Заказы и Товары)
   • КодДеталиЗаказа (Primary Key, Целое число)
   • НомерЗаказа (Foreign Key, Целое число)
   • КодТовара (Foreign Key, Целое число)
   • Количество (Целое число)
   • ЦенаНаМоментЗаказа (Денежный)
7. Счета
   • НомерСчёта (Primary Key, Целое число)
   • НомерЗаказа (Foreign Key, Целое число)
   • ДатаВыставления (Дата/время)
   • ДатаОплаты (Дата/время)
   • СуммаСчёта (Денежный)
   • СтатусОплаты (Текст)

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

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

3.2. Принципы и правила нормализации реляционных баз данных

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

1. Уменьшение избыточности (дублирования) данных: Хранение одной и той же информации в нескольких местах приводит к нерациональному использованию дискового пространства и проблемам при обновлении.
2. Повышение целостности и согласованности данных: Гарантия того, что данные точны, актуальны и непротиворечивы.
3. Избежание аномалий данных: Предотвращение проблем, возникающих при добавлении, обновлении или удалении данных, когда изменения в одном месте не отражаются в других, или когда данные теряются из-за удаления другой информации.

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

Рассмотрим основные нормальные формы:

Первая нормальная форма (1НФ)

Таблица находится в 1НФ, если:

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

Пример нарушения 1НФ:

Заказ	Клиент	Товары_Количество
101	Иванов	Молоко:2, Хлеб:1
102	Петров	Сыр:1

Здесь Товары_Количество неатомарно.

Приведение к 1НФ:

Заказ	Клиент	Товар	Количество
101	Иванов	Молоко	2
101	Иванов	Хлеб	1
102	Петров	Сыр	1

Вторая нормальная форма (2НФ)

Таблица находится во 2НФ, если:

• Она находится в 1НФ.
• Все неключевые атрибуты полностью зависят от всего составного первичного ключа (если ключ составной). То есть, нет частичной функциональной зависимости. Функциональная зависимость X → Y означает, что для каждого значения X существует только одно соответствующее значение Y.

Пример нарушения 2НФ (если первичный ключ: Заказ, Товар):

Заказ	Товар	Количество	ЦенаТовара	НазваниеТовара
101	А1	2	50	Молоко
101	А2	1	30	Хлеб
102	А3	1	100	Сыр

Здесь НазваниеТовара и ЦенаТовара зависят только от Товар (части первичного ключа), а не от всего составного ключа (Заказ, Товар).

Приведение к 2НФ:
Таблица Заказы:

Заказ
101
102

Таблица ДеталиЗаказа:

Заказ	Товар	Количество
101	А1	2
101	А2	1
102	А3	1

Таблица Товары:

Товар	НазваниеТовара	ЦенаТовара
А1	Молоко	50
А2	Хлеб	30
А3	Сыр	100

Третья нормальная форма (3НФ)

Таблица находится в 3НФ, если:

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

Пример нарушения 3НФ:
Таблица Заказы_Сотрудники:

НомерЗаказа	ДатаЗаказа	КодСотрудника	ФИОСотрудника	ДолжностьСотрудника
101	01.11.2025	10	Петров	Менеджер
102	02.11.2025	10	Петров	Менеджер
103	03.11.2025	20	Сидоров	Старший менеджер

Здесь ФИОСотрудника и ДолжностьСотрудника зависят от КодСотрудника (неключевого атрибута), а не напрямую от НомерЗаказа (первичного ключа). Это транзитивная зависимость.

Приведение к 3НФ:
Таблица Заказы:

НомерЗаказа	ДатаЗаказа	КодСотрудника
101	01.11.2025	10
102	02.11.2025	10
103	03.11.2025	20

Таблица Сотрудники:

КодСотрудника	ФИОСотрудника	ДолжностьСотрудника
10	Петров	Менеджер
20	Сидоров	Старший менеджер

Нормальные формы выше 3НФ

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

• Нормальная форма Бойса-Кодда (НФБК / BCNF): Более строгая версия 3НФ. Отношение находится в НФБК, если оно находится в 3НФ, и каждая нетривиальная функциональная зависимость обладает потенциальным ключом в качестве детерминанта. То есть, если X → Y, то X должен быть суперключом (или содержать суперключ). НФБК применяется, когда таблица имеет два или более составных, пересекающихся потенциальных ключа. На практике такие ситуации редки.
• Четвёртая нормальная форма (4НФ): Требует, чтобы отношение находилось в НФБК и не содержало многозначных зависимостей. Многозначная зависимость возникает, когда в таблице есть несколько независимых друг от друга многозначных атрибутов, которые зависят от одного и того же ключа. Это означает, что нетривиальные зависимости должны быть функциональными и зависеть от потенциальных ключей. Применяется, когда один объект имеет несколько независимых коллекций атрибутов.
• Пятая нормальная форма (5НФ): Предполагает, что отношение находится в 4НФ и не содержит зависимостей соединения (join dependency), которые могут быть устранены путём дальнейшей декомпозиции таблицы без потери информации. На практике 5НФ используется крайне редко из-за сложности её достижения и малого количества случаев, когда она необходима. Она связана с возможностью представления информации о сущностях с помощью соединения нескольких таблиц, а не одной.

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

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

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

• Проверка на 2НФ:
  • Таблицы Клиенты, Товары, Заказы, Сотрудники, Поставщики, Счета имеют простые первичные ключи, поэтому для них 2НФ выполняется автоматически, если они уже в 1НФ.
  • Таблица ДеталиЗаказа имеет составной ключ (НомерЗаказа, КодТовара). Поля Количество и ЦенаНаМоментЗаказа зависят от всего ключа, а не от его части. Следовательно, ДеталиЗаказа также находится во 2НФ.
• Проверка на 3НФ:
  • В таблице Заказы поле СуммаЗаказа может быть вычисляемым на основе ДеталиЗаказа. Если она хранится, то это потенциальная избыточность, но не нарушение 3НФ, если она зависит от НомерЗаказа.
  • Предположим, в таблице Товары кроме КодПоставщика мы бы хранили НазваниеПоставщика. Тогда НазваниеПоставщика зависело бы от КодПоставщика (неключевого атрибута), что было бы нарушением 3НФ. Но в нашей текущей структуре НазваниеПоставщика находится в таблице Поставщики, что соответствует 3НФ.
  • Подобным образом, в Заказы мы храним КодСотрудника, а не ФИОСотрудника и ДолжностьСотрудника, которые находятся в таблице Сотрудники. Это также соответствует 3НФ.

Таким образом, разработанная структура таблиц для системы сбыта, скорее всего, уже соответствует 3НФ, что является хорошей основой для её реализации.

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

3.3. Физическое проектирование базы данных в среде MS Access

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

Общие характеристики СУБД MS Access:

MS Access — это не просто база данных, это полноценная система управления базами данных (СУБД), интегрированная в пакет Microsoft Office. Её ключевые особенности:

• Ориентация на малый и средний бизнес: Access идеально подходит для задач, где не требуется высокая нагрузка, но важна простота разработки и использования.
• Файловая архитектура: В отличие от клиент-серверных СУБД (как SQL Server или MySQL), Access хранит всю базу данных в одном файле (.accdb для новых версий, .mdb для старых). Это упрощает развертывание, но накладывает ограничения на масштабируемость и производительность при большом количестве одновременных пользователей.
• Интеграция с Office: Бесшовно взаимодействует с другими приложениями Microsoft Office, такими как Excel, Word, Outlook, что облегчает импорт/экспорт данных, создание отчетов и автоматизацию рабочих процессов.
• Интуитивно понятный интерфейс: Предоставляет графические мастера и конструкторы для создания таблиц, форм, запросов и отчетов, что значительно снижает порог входа для пользователей без глубоких знаний программирования.

Процесс создания таблиц в MS Access:

Создание таблиц — это первый шаг к физической реализации базы данных. В MS Access это обычно делается через Конструктор таблиц:

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

Тип данных в Access	Описание	Пример использования	Ограничения
Короткий текст	Для хранения буквенно-цифровых данных (имена, адреса, артикулы).	ФИО_Название, Адрес, Артикул, СтатусЗаказа	До 255 символов.
Длинный текст	Для хранения большого объема текста (описания, примечания).	Описание (товара)	До 65 536 символов.
Числовой	Для хранения числовых данных, которые будут использоваться в расчетах. Доступны различные подтипы (Байт, Целое, Длинное целое, Одинарное с плавающей точкой, Двойное с плавающей точкой, Код репликации, Decimal).	КодКлиента, Количество	Целое: от -32768 до 32767. Длинное целое: от -2147483648 до 2147483647.
Дата/время	Для хранения дат и времени.	ДатаЗаказа, ДатаОтгрузки	Диапазон от 100 до 9999 года.
Денежный	Для хранения денежных значений с высокой точностью.	ЦенаПродажи, СуммаЗаказа	До 4 десятичных знаков.
Автонумерация	Автоматически генерирует уникальные последовательные числа при добавлении новой записи. Идеально для первичных ключей.	КодКлиента, НомерЗаказа	Длинное целое.
Да/Нет	Для хранения логических значений (истина/ложь, да/нет).	АктивныйКлиент	Логическое значение.
Поле объекта OLE	Для встраивания объектов из других программ (например, изображений, документов Word).	Логотип компании в отчете.	Размер ограничен размером файла БД.
Гиперссылка	Для хранения ссылок на веб-страницы, файлы, адреса электронной почты.	Email (если это не просто текст, а кликабельная ссылка)	Текст до 2048 символов.
Вложение	Для прикрепления нескольких файлов к одной записи.	Фотографии товаров.	Ограничено размером файла БД.
Вычисляемое	Поле, значение которого вычисляется на основе выражений или значений других полей.	ПолнаяСумма = Количество * Цена.	Зависит от типов данных в выражении.
Мастер подстановок	Позволяет создавать поле, которое отображает список значений из другой таблицы или фиксированный список значений. Это не тип данных, а функция, упрощающая ввод и обеспечивающая целостность.	КодКлиента (в Заказах) будет подставлять ФИО_Название из Клиентов.	Фактически хранит внешний ключ.

3. Определение первичных ключей: Для каждой таблицы выбирается поле (или комбинация полей), которое будет однозначно идентифицировать каждую запись. В Конструкторе таблиц для этого используется кнопка «Ключевое поле».

Установка связей между таблицами с помощью схемы данных:

После создания всех таблиц необходимо установить связи между ними, реализуя логику реляционной модели. В Access это делается через инструмент Схема данных (Relationships):

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

Механизмы обеспечения целостности данных в MS Access:

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

1. Условия на значение поля (Field Validation Rule): Это правила, которые применяются к отдельным полям и проверяют вводимые данные на соответствие определённому условию. Если данные не соответствуют условию, Access выводит сообщение об ошибке.
   • Пример: Для поля ЦенаПродажи можно установить условие >0 или >= [ЦенаЗакупки] (для предотвращения продажи в убыток).
   • Сообщение об ошибке для пользователя: «Цена продажи должна быть больше нуля и не ниже цены закупки.»
2. Условия на значения записи (Record Validation Rule): Эти правила применяются ко всей записи и могут проверять взаимосвязь значений в разных полях одной и той же записи.
   • Пример: В таблице Заказы можно установить условие: [ДатаОтгрузки] >= [ДатаЗаказа].
   • Сообщение об ошибке для пользователя: «Дата отгрузки не может быть раньше даты заказа.»
3. Маски ввода (Input Masks): Позволяют задать определённый формат для ввода данных в поле, обеспечивая единообразие и предотвращая ошибки.
   • Пример: Для поля Телефон можно задать маску (999) 000-0000, чтобы пользователи всегда вводили номер в одном формате.
   • Для поля ИНН (для юр. лиц) 0000000000 (10 цифр) или 000000000000 (12 цифр для физ. лиц).
4. Обязательность поля (Required property): Параметр поля, который гарантирует, что оно не может быть оставлено пустым.
5. Уникальность индекса (Unique Index): Позволяет гарантировать, что значения в определённом поле (или комбинации полей) уникальны для всей таблицы.
   • Пример: Для поля Артикул в таблице Товары можно создать уникальный индекс, чтобы каждый артикул был уникальным.

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

Глава 4. Разработка пользовательского интерфейса и функционала системы сбыта в MS Access

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

4.1. Разработка форм для ввода и отображения данных

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

Виды форм в MS Access и их назначение:

1. Одиночные формы (Single Form): Отображают одну запись за раз. Идеальны для детального просмотра или редактирования отдельных объектов, таких как информация о конкретном клиенте или товаре.
2. Ленточные формы (Continuous Forms): Отображают несколько записей одновременно в виде списка, что удобно для быстрого просмотра и навигации по данным (например, список всех заказов).
3. Подчиненные формы (Subforms): Позволяют отображать данные из связанных таблиц в рамках одной основной формы. Это особенно полезно для связей «один-ко-многим». Например, в форме «Заказ» может быть подчиненная форма «ДеталиЗаказа», отображающая все товары, включенные в данный заказ.
4. Разделенные формы (Split Forms): Сочетают ленточную и одиночную форму в одном окне, позволяя просматривать список записей и одновременно детально работать с выбранной записью.
5. Модальные диалоговые формы: Открываются поверх других окон и требуют взаимодействия пользователя, прежде чем он сможет вернуться к основной работе (например, окно подтверждения операции).

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

Рассмотрим примеры проектирования форм для ключевых сущностей нашей системы сбыта:

• Форма «Клиенты»:
  • Назначение: Ввод, просмотр и редактирование информации о клиентах.
  • Тип: Одиночная или разделенная форма.
  • Элементы управления:
    • Текстовые поля для КодКлиента, ФИО_Название, Адрес, Телефон, Email, ИНН, КПП, БанковскиеРеквизиты.
    • Поле «Дата/время» для ДатаРегистрации.
    • Кнопки для навигации («Следующий», «Предыдущий»), сохранения, удаления записи.
    • Возможно, подчиненная форма для отображения истории заказов данного клиента.
• Форма «Товары»:
  • Назначение: Учёт и управление ассортиментом товаров.
  • Тип: Одиночная форма.
  • Элементы управления:
    • Текстовые поля для КодТовара, НазваниеТовара, Артикул, ЕдиницаИзмерения, Описание.
    • Числовые или денежные поля для ЦенаЗакупки, ЦенаПродажи.
    • Поле со списком (Combo Box) для КодПоставщика, отображающее НазваниеПоставщика из таблицы Поставщики для удобного выбора.
    • Кнопки для действий.
• Форма «Заказы»:
  • Назначение: Создание, отслеживание и управление клиентскими заказами.
  • Тип: Одиночная форма с подчиненной формой.
  • Элементы управления:
    • Текстовое поле для НомерЗаказа.
    • Поле со списком для КодКлиента (отображает ФИО_Название клиента).
    • Поле со списком для КодСотрудника (отображает ФИО сотрудника).
    • Поля «Дата/время» для ДатаЗаказа, ДатаОтгрузки.
    • Поле со списком для СтатусЗаказа (например, «Новый», «В обработке», «Отгружен», «Оплачен», «Отменен»).
    • Вычисляемое поле для СуммаЗаказа (автоматически рассчитывается на основе подчиненной формы ДеталиЗаказа).
    • Подчиненная форма «ДеталиЗаказа»: Это ленточная форма, отображающая все товары, включенные в текущий заказ. В ней будут поля КодТовара (с полем со списком для выбора НазванияТовара), Количество, ЦенаНаМоментЗаказа.

Использование различных элементов управления формами:

• Текстовые поля (Text Box): Для ввода и отображения текстовых и числовых данных.
• Кнопки (Command Button): Для выполнения макросов или кода VBA (например, «Сохранить», «Удалить», «Печать», «Открыть отчет»).
• Списки (List Box) и Поля со списком (Combo Box): Для выбора значений из предопределенного списка или другой таблицы, что повышает скорость ввода и обеспечивает целостность данных.
• Переключатели (Option Button) и Группы переключателей (Option Group): Для выбора одного значения из нескольких предустановленных вариантов.
• Флажки (Check Box): Для логических значений «да/нет».
• Вкладки (Tab Control): Для организации большого количества информации на нескольких страницах в одной форме, улучшая навигацию.
• Метки (Label): Для отображения статичного текста.

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

4.2. Создание запросов для извлечения и обработки данных

Запросы — это сердце любой базы данных, позволяющее извлекать, фильтровать, сортировать и манипулировать данными в соответствии с определёнными критериями. В MS Access запросы играют центральную роль в анализе информации, формировании отчётов и подготовке данных для форм.

Виды запросов в MS Access:

MS Access поддерживает различные типы запросов, каждый из которых предназначен для выполнения специфических задач:

1. Выборочные запросы (Select Queries): Самый распространённый тип. Используются для извлечения данных из одной или нескольких таблиц, фильтрации записей, сортировки и выполнения расчётов.
   • Пример: «Показать все заказы за последний месяц».
2. Перекрестные запросы (Crosstab Queries): Вычисляют сумму, среднее значение, количество или другие агрегатные функции для данных, сгруппированных по двум или более полям. Результат представляется в виде таблицы со строками и столбцами, что удобно для сводного анализа.
   • Пример: «Сумма продаж по товарам в разрезе менеджеров».
3. Запросы на изменение данных (Action Queries): Эти запросы изменяют данные в таблицах. Они могут быть:
   • Запросы на обновление (Update Queries): Изменяют значения в существующих записях.
     • Пример: «Увеличить цену всех товаров на 5%».
   • Запросы на добавление (Append Queries): Добавляют записи из одной таблицы в другую.
     • Пример: «Перенести завершенные заказы в архивную таблицу».
   • Запросы на удаление (Delete Queries): Удаляют записи из таблицы.
     • Пример: «Удалить все заказы старше 5 лет».
   • Запросы на создание таблицы (Make-Table Queries): Создают новую таблицу на основе результатов запроса.
     • Пример: «Создать таблицу с ежемесячным отчётом о продажах».

Разработка примеров запросов, необходимых для системы сбыта:

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

1. «Запрос о продажах за период» (Выборочный запрос):
   • Назначение: Получить информацию о продажах за определённый временной интервал, включая данные о клиентах и товарах.
   • Поля: НомерЗаказа, ДатаЗаказа, ФИО_Название (клиента), НазваниеТовара, Количество, ЦенаНаМоментЗаказа, СуммаСтроки (Количество * ЦенаНаМоментЗаказа).
   • Условие: ДатаЗаказа между [Начальная дата] и [Конечная дата].
   • Таблицы: Заказы, Клиенты, ДеталиЗаказа, Товары.
2. «Запрос об остатках товаров» (Выборочный запрос с группировкой):
   • Назначение: Показать текущие остатки товаров на складе (если допустить, что мы храним только проданные, а не все поступления). Для более сложного учета потребуется таблица «Склад».
   • Поля: НазваниеТовара, Артикул, СуммаКоличеств (сгруппированная по НазваниеТовара и Артикул из ДеталиЗаказа и Товары).
   • Условие: Возможно, СтатусЗаказа не «Отменен».
   • Таблицы: Товары, ДеталиЗаказа.
3. «Запрос о задолженностях клиентов» (Выборочный запрос):
   • Назначение: Выявить клиентов, которые имеют неоплаченные счета.
   • Поля: ФИО_Название (клиента), НомерЗаказа, НомерСчёта, ДатаВыставления, СуммаСчёта, СтатусОплаты.
   • Условие: СтатусОплаты = «Не оплачен» или СтатусОплаты = «Частично оплачен».
   • Таблицы: Клиенты, Заказы, Счета.
4. «Ежемесячный отчёт по менеджерам» (Перекрестный запрос):
   • Назначение: Сформировать сводный отчёт о продажах по каждому менеджеру за каждый месяц.
   • Поля заголовков строк: ФИО (сотрудника).
   • Поля заголовков столбцов: Формат([ДатаЗаказа];"ММММ ГГГГ") (месяц и год).
   • Значение: Сумма([Количество] * [ЦенаНаМоментЗаказа]).
   • Таблицы: Сотрудники, Заказы, ДеталиЗаказа, Товары.

Возможности использования SQL в MS Access:

Хотя MS Access предоставляет удобный графический конструктор запросов, за каждым запросом стоит язык SQL (Structured Query Language). Пользователь может переключиться в режим «SQL» в Конструкторе запросов, чтобы увидеть сгенерированный код или написать собственный. Это даёт гибкость и позволяет создавать более сложные запросы, которые трудно или невозможно реализовать с помощью графического интерфейса.

Пример SQL для «Запроса о продажах за период»:

SELECT
    Заказы.НомерЗаказа,
    Заказы.ДатаЗаказа,
    Клиенты.ФИО_Название AS Клиент,
    Товары.НазваниеТовара,
    ДеталиЗаказа.Количество,
    ДеталиЗаказа.ЦенаНаМоментЗаказа,
    (ДеталиЗаказа.Количество * ДеталиЗаказа.ЦенаНаМоментЗаказа) AS СуммаСтроки
FROM
    Клиенты
INNER JOIN
    Заказы ON Клиенты.КодКлиента = Заказы.КодКлиента
INNER JOIN
    ДеталиЗаказа ON Заказы.НомерЗаказа = ДеталиЗаказа.НомерЗаказа
INNER JOIN
    Товары ON ДеталиЗаказа.КодТовара = Товары.КодТовара
WHERE
    Заказы.ДатаЗаказа BETWEEN [Начальная дата] AND [Конечная дата];

Владение SQL значительно расширяет возможности разработчика в MS Access, позволяя создавать более мощные и точные инструменты для работы с данными.

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

4.3. Разработка отчетов и автоматизация задач

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

Назначение отчетов в информационной системе:

Отчёты выполняют несколько ключевых функций:

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

Создание отчетов для системы сбыта:

В MS Access отчёты создаются с использованием мастеров или конструктора отчётов. Основные этапы:

1. Выбор источника данных: Отчёт может основываться на таблице или запросе. Часто лучше использовать запрос, чтобы предварительно отфильтровать, отсортировать или сгруппировать данные.
2. Группировка и сортировка: В конструкторе отчётов можно легко настроить группировку данных (например, по клиенту, по дате заказа) и порядок сортировки.
3. Добавление полей и элементов управления: Перетаскивание полей из источника данных, добавление текстовых полей, меток, изображений, а также вычисляемых полей.
4. Форматирование: Настройка внешнего вида отчёта (шрифты, цвета, границы, заголовки, колонтитулы) для улучшения читаемости.

Примеры отчетов для системы сбыта:

• «Отчет о продажах» (по датам):
  • Назначение: Сводная информация о продажах за определённый период.
  • Источник: Запрос «Запрос о продажах за период».
  • Структура: Группировка по ДатаЗаказа, детализация по НомерЗаказа, НазваниеТовара, Количество, ЦенаНаМоментЗаказа, СуммаСтроки. В конце каждой группы и отчёта — итоговые суммы.
• «Прайс-лист»:
  • Назначение: Список всех товаров с актуальными ценами.
  • Источник: Таблица Товары или простой запрос к ней.
  • Структура: Простое отображение полей Артикул, НазваниеТовара, Описание, ЦенаПродажи. Сортировка по НазваниюТовара.
• «Отчет по заказам» (детализированный):
  • Назначение: Полная информация по каждому заказу, включая данные клиента, сотрудника и все позиции заказа.
  • Источник: Сложный запрос, объединяющий Заказы, Клиенты, Сотрудники, ДеталиЗаказа, Товары.
  • Структура: Группировка по НомерЗаказа. В верхней части — данные заказа, клиента и сотрудника. Внизу — детализация товаров в заказе (с использованием подчиненного отчета или группировки).

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

MS Access предоставляет два основных инструмента для автоматизации:

1. Макросы (Macros): Это последовательности действий, которые можно выполнять без написания кода. Макросы подходят для простых задач.
   • Примеры:
     • Открытие форм: Макрос для кнопки «Открыть форму Клиенты».
     • Печать отчетов: Макрос для кнопки «Печать отчета о продажах».
     • Проверка данных: Простые макросы SetWarnings для отключения/включения системных предупреждений.
     • Фильтрация: Макрос для фильтрации записей в форме по определённому критерию.
2. VBA (Visual Basic for Applications): Это мощный язык программирования, встроенный в Access. VBA позволяет создавать сложную логику, обрабатывать события, взаимодействовать с другими приложениями Office и выполнять операции, недоступные в макросах.
   • Примеры:
     • Автоматическое формирование номера заказа: При создании новой записи в форме «Заказ», VBA может автоматически сгенерировать уникальный номер.
     • Динамическое обновление полей: При изменении количества товара в ДеталиЗаказа, VBA может автоматически пересчитать СуммаЗаказа в основной форме Заказ.
     • Отправка уведомлений: При изменении статуса заказа, VBA может отправить email клиенту или менеджеру через Outlook.
     • Расширенная проверка данных: Более сложные правила проверки, которые невозможно реализовать через стандартные условия на значение поля или записи.
     • Взаимодействие с внешними системами: Экспорт данных в специализированные форматы или импорт из них.

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

Глава 5. Преимущества, ограничения и перспективы использования MS Access для систем сбыта

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

5.1. Анализ преимуществ MS Access

Microsoft Access, несмотря на свою «desktop-ориентированность» и наличие более мощных серверных СУБД, продолжает оставаться популярным выбором для определённых категорий задач и пользователей. Для системы сбыта малого и среднего предприятия он обладает рядом существенных преимуществ:

1. Простота освоения и интуитивно понятный интерфейс:
   • Access разработан с учётом потребностей пользователей, не являющихся профессиональными программистами или администраторами баз данных. Его графический интерфейс, мастера и конструкторы позволяют быстро создавать таблицы, формы, запросы и отчёты. Это снижает порог входа для студентов и представителей малого бизнеса, позволяя им самостоятельно разрабатывать и поддерживать простые информационные системы.
   • Визуальные инструменты, такие как «Конструктор таблиц», «Мастер запросов» или «Мастер форм», значительно ускоряют процесс разработки, предоставляя готовые шаблоны и шаги.
2. Высокая степень интеграции с другими продуктами Microsoft Office:
   • Access является частью экосистемы Microsoft Office, что обеспечивает бесшовное взаимодействие с другими приложениями.
     • Excel: Легкий импорт и экспорт данных, а также связь с листами Excel для анализа или использования в качестве внешнего источника. Это удобно для обработки прайс-листов поставщиков или экспорта отчетов для дальнейшей работы.
     • Word: Использование данных Access для слияния почты в Word (например, для автоматической генерации договоров, коммерческих предложений или писем клиентам).
     • Outlook: Автоматизация отправки уведомлений или отчетов по электронной почте с использованием данных из БД.
     • PowerPoint: Возможность встраивания таблиц или графиков из Access в презентации.
   • Эта интеграция повышает производительность и позволяет использовать уже привычные инструменты для расширения функционала системы сбыта.
3. Экономическая эффективность и доступность для малого и среднего бизнеса:
   • Access часто входит в состав пакета Microsoft Office, который уже приобретён большинством организаций. Это означает отсутствие дополнительных затрат на лицензирование СУБД, что делает его крайне привлекательным решением с точки зрения начальных инвестиций.
   • Для малого бизнеса, не имеющего собственного IT-отдела или значительного бюджета, Access является «более мягкой» версией систем на архитектуре клиент/сервер, предоставляя возможности автоматизации без необходимости вкладываться в дорогостоящее серверное оборудование и специализированное ПО.
4. Гибкость в настройке и адаптации под конкретные задачи:
   • Access позволяет создавать персонализированные базы данных, которые точно соответствуют уникальным бизнес-процессам организации. Разработчик может определять собственные таблицы, связи, формы, запросы и отчёты.
   • Эта гибкость делает его отличным инструментом для быстрого создания прототипов информационных систем, тестирования гипотез и адаптации к изменяющимся требованиям бизнеса. Он подходит для учёта инвентаризации, управления контактами, небольших CRM-систем и различных бизнес-процессов, включая систему сбыта.
5. Поддержка многопользовательского режима и автоматизации:
   • Несмотря на файловую архитектуру, Access поддерживает многопользовательский режим, позволяя нескольким пользователям одновременно работать с одной базой данных, расположенной, например, на сетевом диске. Можно настроить права доступа для разных пользователей.
   • Функционал макросов и VBA (Visual Basic for Applications) позволяет автоматизировать множество рутинных операций, таких как формирование отчётов по расписанию, отправка уведомлений, выполнение сложных расчётов или проверка данных, что значительно повышает эффективность работы сотрудников отдела сбыта.

В целом, MS Access предлагает комплексное, доступное и достаточно мощное решение для автоматизации бизнес-процессов, особенно в условиях ограниченных ресурсов малых и средних предприятий.

5.2. Ограничения и потенциальные проблемы при использовании MS Access

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

1. Ограничение размера файла базы данных и количества объектов:
   • Основное ограничение: общий размер файла базы данных Access (формата .accdb или .mdb) не может превышать 2 ГБ. Это включает в себя не только данные, но и все объекты базы данных (таблицы, формы, запросы, отчёты, макросы, модули).
   • Хотя можно обойти это ограничение, создавая связи с та��лицами из других баз данных Access (каждая из которых также имеет лимит в 2 ГБ), это усложняет администрирование и не является полноценным решением для очень больших объемов данных.
   • Ограничение количества объектов: Максимальное количество объектов в одной базе данных составляет 32 768, а количество модулей (включая формы и отчёты со свойством HasModule = Истина) ограничено 1 000. Для крупных систем это может стать препятствием.
2. Ограничение на количество одновременно работающих пользователей и масштабируемости (горизонтальной):
   • MS Access поддерживает до 255 одновременно работающих пользователей. Однако на практике производительность начинает существенно снижаться уже при 10-20 активных пользователях, особенно при интенсивной записи данных.
   • Файловая архитектура, когда один файл базы данных хранится на сетевом диске, приводит к тому, что при каждом запросе или обновлении Access загружает часть файла на клиентскую машину, обрабатывает её и записывает обратно. Это создаёт высокую нагрузку на сеть и дисковую подсистему, вызывая задержки и проблемы с производительностью.
   • Низкая горизонтальная масштабируемость: Распределение таблиц данных по множеству серверов (горизонтальное масштабирование), что характерно для больших реляционных СУБД, является слабой стороной Access. С разрастанием системы могут появляться задержки в обновлении данных, что может нарушить принцип целостности и привести к блокировкам.
3. Ограничения типов данных:
   • Существуют определённые ограничения на размер и диапазон значений для различных типов данных, которые могут быть недостаточными для очень больших объёмов информации или специфических расчётов:
     • Короткий текст (Short Text): До 255 символов (255 байт).
     • Длинный текст (Long Text/Memo): До 65 536 символов.
     • Целое (Integer): Диапазон от -32768 до 32767 (2 байта).
     • Длинное целое (Long Integer): Диапазон от -2147483648 до 2147483647 (4 байта).
   • Для некоторых числовых расчётов или хранения уникальных идентификаторов в глобальных системах эти диапазоны могут быть слишком малы.
4. Уступает более продвинутым СУБД:
   • В сравнении с мощными клиент-серверными СУБД, такими как Microsoft SQL Server, MySQL, PostgreSQL, Oracle Database, Access значительно уступает по:
     • Масштабируемости: Не предназначен для обработки десятков тысяч транзакций в секунду или хранения терабайтов данных.
     • Производительности: При высокой нагрузке или сложности запросов серверные СУБД с их оптимизаторами запросов, многопоточной обработкой и кэшированием демонстрируют гораздо лучшие результаты.
     • Надёжности и безопасности: Серверные СУБД имеют более развитые механизмы резервного копирования, восстановления, репликации, а также более гранулированные системы прав доступа и аудита.
     • Возможностям программирования: Поддерживают хранимые процедуры, триггеры, функции на стороне сервера, которые значительно расширяют функционал и повышают производительность, чего нет в Access.
   • Сценарии перехода: Если система сбыта предприятия активно развивается, количество клиентов и товаров растёт, а число пользователей увеличивается, неизбежно возникнет необходимость перехода на более мощные клиент-серверные СУБД. Access может выступать как отличное «стартовое решение» или «фронтенд» для серверной базы данных (подключаясь к таблицам SQL Server), но не как полноценный бэкенд для крупного бизнеса.

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

5.3. Рекомендации по оптимизации и перспективы развития информационной системы сбыта на базе Access

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

Рекомендации по повышению производительности и надежности разработанной БД:

1. Разделение базы данных (Frontend/Backend): Это наиболее важная рекомендация для Access в многопользовательской среде. Разделите базу данных на две части:
   • Backend (серверная часть): Содержит только таблицы с данными и хранится на сетевом диске.
   • Frontend (клиентская часть): Содержит формы, запросы, отчёты, макросы, VBA-код и ссылки на таблицы Backend. Каждый пользователь работает со своей копией Frontend на локальном компьютере.

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

2. Регулярное сжатие и восстановление базы данных: Файлы Access имеют свойство увеличиваться в размере со временем из-за удалённых объектов и данных. Регулярное использование функции «Сжать и восстановить базу данных» (в меню «Файл» > «Сведения») помогает оптимизировать размер файла и восстановить его структуру, улучшая производительность.
3. Индексирование полей: Создавайте индексы для полей, которые часто используются в условиях поиска (WHERE), сортировки (ORDER BY), группировки (GROUP BY) или для установления связей (внешние ключи). Это ускоряет выполнение запросов. Однако чрезмерное индексирование может замедлить операции добавления/обновления данных.
4. Оптимизация запросов:
   • Используйте конструктор запросов для визуальной проверки их структуры.
   • Избегайте использования функций в условиях WHERE для индексированных полей (например, YEAR(ДатаЗаказа)=2025 вместо ДатаЗаказа BETWEEN #01/01/2025# AND #31/12/2025#).
   • Используйте явные соединения (INNER JOIN) вместо неявных в предложении FROM.
5. Архивирование старых данных: При достижении лимита в 2 ГБ или просто для повышения производительности, рассмотрите возможность переноса исторически неактуальных данных (например, заказов старше 5 лет) в отдельную архивную базу данных Access или даже в текстовые файлы/Excel.
6. Использование правил проверки и масок ввода: Как было описано ранее, эти механизмы помогают предотвратить ввод некорректных данных, что критически важно для целостности системы сбыта.
7. Резервное копирование: Настройте регулярное автоматическое или ручное резервное копирование файла базы данных Backend. Это жизненно важно для защиты от потери данных.

Возможности дальнейшего развития и интеграции информационной системы:

1. Расширение функционала:
   • CRM-модуль: Добавление функций для отслеживания взаимодействия с клиентами, планирования звонков и встреч.
   • Модуль маркетинга: Управление рассылками, акциями, сегментацией клиентов.
   • Модуль складского учёта: Более детальный учёт прихода/расхода товаров, инвентаризация, работа с несколькими складами.
   • Модуль отчетности: Разработка более сложных аналитических отчётов и дашбордов.
2. Интеграция с внешними системами:
   • Сайт/интернет-магазин: Синхронизация данных о товарах, заказах, клиентах. Это может потребовать использования промежуточных веб-сервисов или специальных коннекторов.
   • Бухгалтерские системы (1С, SAP): Экспорт данных для бухгалтерского учёта, импорт данных о платежах.
   • Платежные системы: Интеграция для автоматической обработки оплат.
3. Переход на клиент-серверную архитектуру:
   • При значительном росте предприятия, увеличении объёма данных и числа пользователей, Access перестанет справляться. Стратегическое развитие подразумевает миграцию на более мощные СУБД, такие как SQL Server Express (бесплатная версия для небольших нагрузок), MySQL или PostgreSQL.
   • Access может быть использован как «фронтенд» (интерфейсная часть), подключаясь к таблицам на SQL Server (т.н. «связывание таблиц»). Это позволяет сохранить привычный интерфейс для пользователей, при этом используя мощь серверной СУБД для хранения и обработки данных.

Стратегическая роль Access для малого и среднего бизнеса и её место в современной IT-экосистеме:

MS Access занимает уникальное положение в IT-ландшафте. Он является отличным инструментом для:

• Быстрого прототипирования и MVP (Minimum Viable Product): Позволяет быстро создать работающую систему для проверки бизнес-идей.
• Персональных и departmental баз данных: Идеален для нужд одного пользователя или небольшого отдела, где не требуется сложная инфраструктура.
• Обучения: Служит прекрасной платформой для изучения основ проектирования баз данных и SQL.
• Фронтенда для серверных СУБД: Позволяет использовать привычный графический интерфейс для взаимодействия с более мощными серверными базами данных, продлевая срок службы существующего ПО и снижая затраты на обучение новых систем.

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

Заключение

В рамках данной курсовой работы был разработан структурированный план для проектирования информационной базы данных системы сбыта предприятия с использованием MS Access, а также последовательно раскрыты все ключевые аспекты этого процесса. Мы начали с теоретических основ, определив фундаментальные понятия реляционных баз данных, таких как сущности, атрибуты и связи, и рассмотрели исторический вклад Эдгара Ф. Кодда. Были подробно описаны этапы проектирования — концептуальное, логическое и физическое — с акцентом на методологию ER-моделирования и обзор CASE-средств.

Глубокий анализ предметной области «Система сбыта предприятия» позволил выявить основные бизнес-процессы, функциональные требования, ключевые сущности, их атрибуты и взаимосвязи, что стало основой для построения наглядной инфологической модели в виде ER-диаграммы. На этапе логического проектирования эта модель была преобразована в реляционную схему, а затем детально рассмотрены принципы и правила нормализации до 3НФ, а также углубленный анализ нормальных форм Бойса-Кодда, 4НФ и 5НФ, объясняющий их практическое применение. Физическое проектирование базы данных в MS Access включало описание создания таблиц, выбора типов данных, установки связей и, что особенно важно, детализацию механизмов обеспечения целостности данных, таких как условия на значение поля и маски ввода.

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

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

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

Список использованных источников

{Текст: Студент должен будет привести список источников, соответствующих критериям авторитетности.}

Приложения

{Текст: Студент должен будет включить ER-диаграмму системы сбыта, схему данных MS Access, а также скриншоты основных форм, запросов и отчетов разработанной информационной системы.}

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

1. Вейскас, Д. Эффективная работа с ACCESS. Санкт-Петербург, 1996.
2. Реляционная база данных // Википедия. URL: https://ru.wikipedia.org/wiki/%D0%A0%D0%B5%D0%BB%D1%8F%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%B0%D1%8F_%D0%B1%D0%B0%D0%B7%D0%B0_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85 (дата обращения: 03.11.2025).
3. СУБД: что это, виды, структура, функции // Яндекс Практикум. URL: https://practicum.yandex.ru/blog/chto-takoe-subd/ (дата обращения: 03.11.2025).
4. Проектирование реляционных баз данных: основные принципы // Habr. URL: https://habr.com/ru/articles/731118/ (дата обращения: 03.11.2025).
5. Что такое реляционная база данных // Selectel. URL: https://selectel.ru/blog/what-is-relational-database/ (дата обращения: 03.11.2025).
6. Что такое СУБД? Наиболее популярные СУБД // RU-CENTER помощь. URL: https://www.nic.ru/help/articles/chto-takoe-subd/ (дата обращения: 03.11.2025).
7. Что такое реляционная база данных? // Amazon Web Services (AWS). URL: https://aws.amazon.com/ru/relational-database/ (дата обращения: 03.11.2025).
8. Система управления базами данных (СУБД): что это такое и зачем нужна // Cloud.ru. URL: https://cloud.ru/docs/d/what-is-database-management-system (дата обращения: 03.11.2025).
9. Реляционные базы данных: основные принципы, структура и характеристики // Yandex Cloud — Документация. URL: https://cloud.yandex.ru/docs/glossary/relational-database (дата обращения: 03.11.2025).
10. СУБД — что это: Системы Управления Базами Данных // Skillfactory media. URL: https://skillfactory.ru/blog/chto-takoe-subd-vidy-i-primery/ (дата обращения: 03.11.2025).
11. Нормализация данных: что это и зачем она нужна // Skypro. URL: https://sky.pro/wiki/it/normalizatsiya-dannykh/ (дата обращения: 03.11.2025).
12. Нормальная форма // Википедия. URL: https://ru.wikipedia.org/wiki/%D0%9D%D0%BE%D1%80%D0%BC%D0%B0%D0%BB%D1%8C%D0%BDBA%D1%8F_%D1%84%D0%BE%D1%80%D0%BC%D0%B0 (дата обращения: 03.11.2025).
13. Для решения каких задач может потребоваться Microsoft Access // IT-course.kz. URL: https://it-course.kz/stati/dlya-resheniya-kakikh-zadach-mozhet-potrebovatsya-microsoft-access/ (дата обращения: 03.11.2025).
14. Что такое нормализация баз данных? // Otus. URL: https://otus.ru/journal/chto-takoe-normalizaciya-baz-dannyh/ (дата обращения: 03.11.2025).
15. Access: что такое и как это работает // Skyeng. URL: https://skyeng.ru/articles/access-chto-takoe-i-kak-eto-rabotaet/ (дата обращения: 03.11.2025).
16. Нормализация базы данных: для чего нужна нормализованная бд // GitVerse Blog. URL: https://gitverse.ru/blog/normalization-database/ (дата обращения: 03.11.2025).
17. Ограничения типов данных MS Access // Восток ИТ. URL: https://vostok-it.ru/programmy/access/ogranicheniya-tipov-dannykh-ms-access.html (дата обращения: 03.11.2025).
18. 5 причин, по которым малому бизнесу следует выбрать MS Access // DataNumen. URL: https://www.datanumen.com/ru/blogs/5-reasons-why-small-business-should-choose-ms-access/ (дата обращения: 03.11.2025).
19. Этапы проектирования баз данных. Концептуальное, логическое и физическое проектирование // Farabi University. URL: https://www.farabi.university/blog/etapy-proektirovaniya-baz-dannyh (дата обращения: 03.11.2025).
20. Описание нормализации базы данных // Microsoft 365 Apps. URL: https://support.microsoft.com/ru-ru/office/%D0%BE%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D0%B5-%D0%BD%D0%BE%D1%80%D0%BC%D0%B0%D0%BB%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D0%B8-%D0%B1%D0%B0%D0%B7%D1%8B-%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85-c990b503-a159-4a00-af15-a7b620950711 (дата обращения: 03.11.2025).
21. Нормализация в реляционных базах данных: глубокий взгляд // AppMaster. URL: https://appmaster.io/ru/blog/normalizaciya-v-relyacionnyh-bazah-dannyh (дата обращения: 03.11.2025).
22. Принципы поддержки целостности в реляционной модели данных // Интуит. URL: https://www.intuit.ru/studies/courses/103/103/lecture/2924?page=1 (дата обращения: 03.11.2025).
23. Примеры и принципы нормализации реляционных баз данных (БД) // DecoSystems. URL: https://decosystems.ru/blog/normalizaciya-baz-dannyx/ (дата обращения: 03.11.2025).
24. Проектирование баз данных // Википедия. URL: https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_%D0%B1%D0%B0%D0%B7_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85 (дата обращения: 03.11.2025).
25. Реляционные базы данных | Нормализация // Metanit. URL: https://metanit.com/sql/database/2.6.php (дата обращения: 03.11.2025).
26. Нормализация базы данных: основные принципы // DECO systems. URL: https://decosystems.ru/blog/normalizaciya-baz-dannyh-osnovnye-principy/ (дата обращения: 03.11.2025).
27. Моделирование данных: концептуальная, логическая и физическая модели // Экстрактор 1С. URL: https://extractor.1c.ru/blog/modelirovanie-dannyh-kontseptualnaya-logicheskaya-i-fizicheskaya-modeli/ (дата обращения: 03.11.2025).
28. Нормализация СУБД: пример базы данных 1NF, 2NF, 3NF // Guru99. URL: https://www.guru99.com/ru/database-normalization.html (дата обращения: 03.11.2025).
29. Проектирование баз данных: основные этапы, методы и модели БД // DECO systems. URL: https://decosystems.ru/blog/proektirovanie-baz-dannyx/ (дата обращения: 03.11.2025).
30. Нормализация отношений. Шесть нормальных форм // Habr. URL: https://habr.com/ru/articles/254479/ (дата обращения: 03.11.2025).
31. MS Access – один из лучших инструментов для обработки данных // proaccess.ru. URL: https://proaccess.ru/ms-access-odin-iz-luchshikh-instrumentov-dlya-obrabotki-dannykh/ (дата обращения: 03.11.2025).
32. Как преодолеть ограничения размера, связанные с базами данных Access // DataNumen. URL: https://www.datanumen.com/ru/blogs/how-to-overcome-size-limitations-associated-with-access-databases/ (дата обращения: 03.11.2025).
33. Спецификации Access // Служба поддержки Майкрософт. URL: https://support.microsoft.com/ru-ru/office/%D1%81%D0%BF%D0%B5%D1%86%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D0%B8-access-0b0213bd-170f-431e-924d-7f543e3347aa (дата обращения: 03.11.2025).
34. Проблема избыточности в базе данных // AndreyEx. URL: https://andreyex.ru/bazy-dannyx/problema-izbytochnosti-v-baze-dannyx/ (дата обращения: 03.11.2025).
35. Ограничение ввода данных с помощью правил проверки // Microsoft Support. URL: https://support.microsoft.com/ru-ru/office/%D0%BE%D0%B3%D1%80%D0%B0%D0%BD%D0%B8%D1%87%D0%B5%D0%BD%D0%B8%D0%B5-%D0%B2%D0%B2%D0%BE%D0%B4%D0%B0-%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85-%D1%81-%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%D1%8C%D1%8E-%D0%BF%D1%80%D0%B0%D0%B2%D0%B8%D0%BB-%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D0%BA%D0%B8-1e4222bb-6577-4475-849a-e274ba1a8a29 (дата обращения: 03.11.2025).
36. База данных Microsoft Access достигла лимита размера. // Reddit. URL: https://www.reddit.com/r/learnprogramming/comments/d1v43r/microsoft_access_database_has_hit_size_limit/ (дата обращения: 03.11.2025).
37. Unlocking the Power of Microsoft Access for Small Businesses // DataNumen. 28.07.2025. URL: https://datanumen.com/blogs/2025/07/28/unlocking-power-microsoft-access-small-businesses/ (дата обращения: 03.11.2025).