Проектирование и Управление Реляционными Базами Данных: От Основ к Современным Вызовам

В современном мире, где объемы информации удваиваются каждые несколько лет, эффективное управление данными становится не просто важным, а критически значимым фактором успеха в любой сфере. От электронных таблиц до сложных систем, обрабатывающих петабайты информации, принципы организации данных остаются краеугольным камнем. Реляционные базы данных (РБД), разработанные в 1970-х годах Эдгаром Ф. Коддом, на протяжении десятилетий остаются эталоном надежности, структурированности и предсказуемости. Именно их строгая, математически обоснованная модель позволяет эффективно хранить, извлекать и манипулировать данными, обеспечивая их целостность и согласованность.

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

Фундаментальные принципы реляционных баз данных

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

Что такое реляционная база данных?

В своей основе реляционная база данных (РБД) представляет собой структурированный набор данных, организованных в виде таблиц, индексов и представлений, где данные связаны между собой по определенным правилам. Идея проста, но гениальна: вместо хранения всей информации в одной громоздкой структуре, реляционная модель разделяет данные на логические, легко управляемые части, представленные в виде двумерных таблиц. Каждая такая таблица предназначена для хранения информации об определенной сущности или объекте предметной области, например, о студентах, книгах или заказах.

Каждая таблица состоит из:

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

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

Основные принципы организации и функционирования

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

Ключевую роль в установлении связей играют ключи:

• Первичный ключ (Primary Key): Это один или несколько атрибутов, которые уникально идентифицируют каждую строку в таблице. Например, «Номер зачётной книжки» может быть первичным ключом для таблицы «Студенты», поскольку двух студентов с одинаковым номером быть не может. Первичный ключ не может содержать повторяющихся значений и не может быть пустым (NULL).
• Внешний ключ (Foreign Key): Это один или несколько атрибутов в одной таблице (дочерней), которые ссылаются на первичный ключ другой таблицы (родительской). Внешний ключ создает логическую связь между таблицами. Например, в таблице «Оценки» может быть поле «Номер зачётной книжки» (внешний ключ), которое ссылается на первичный ключ «Номер зачётной книжки» в таблице «Студенты». Это позволяет понять, какой оценке какого студента соответствует.

Таблица 1. Пример связи между таблицами «Студенты» и «Оценки»

Таблица «Студенты»		Таблица «Оценки»
Студент_ID (ПК)	Имя	Фамилия		Оценка_ID (ПК)	Студент_ID (ВК)	Предмет	Балл
101	Иван	Петров		1	101	Математика	90
102	Мария	Сидорова		2	101	Физика	85
103	Анна	Козлова		3	102	Математика	95

ПК – Первичный ключ, ВК – Внешний ключ

Для взаимодействия с реляционными базами данных используется SQL (Structured Query Language) – декларативный язык, который стал стандартом ANSI с 1986 года. SQL позволяет создавать, изменять и удалять таблицы, а также вставлять, обновлять, удалять и извлекать данные. Его универсальность и мощь делают его незаменимым инструментом для работы с РБД.

Свойства ACID: гарантия надежности данных

В мире баз данных, где точность и надежность информации имеют первостепенное значение, особенно при выполнении транзакций (например, банковских операций), была разработана концепция ACID – акроним, объединяющий четыре ключевых свойства, гарантирующих корректность и устойчивость операций с данными: Atomicity (Атомарность), Consistency (Согласованность), Isolation (Изолированность) и Durability (Устойчивость). Что дают эти свойства разработчику? Прежде всего, уверенность в том, что даже при сбоях системы данные останутся непротиворечивыми и операции будут выполнены корректно, что является основой для построения надёжных бизнес-приложений.

• Атомарность (Atomicity): Это свойство означает, что транзакция рассматривается как единое, неделимое целое. Либо все операции в транзакции выполняются успешно, либо ни одна из них не выполняется. Если в процессе выполнения транзакции происходит сбой, система автоматически отменяет все выполненные до этого шаги, возвращая базу данных в исходное состояние. Например, перевод денег с одного счета на другой включает две операции: списание с первого счета и зачисление на второй. Атомарность гарантирует, что либо обе операции пройдут успешно, либо ни одна из них не будет выполнена, предотвращая потерю денег.
• Согласованность (Consistency): Это свойство гарантирует, что каждая успешно завершенная транзакция переводит базу данных из одного согласованного состояния в другое согласованное состояние. Это означает, что все ограничения целостности (такие как уникальность ключей, ссылочная целостность, правила домена) должны соблюдаться как до, так и после выполнения транзакции. База данных никогда не останется в некорректном или противоречивом состоянии.
• Изолированность (Isolation): Это свойство определяет, что параллельно выполняющиеся транзакции не должны влиять друг на друга. С точки зрения пользователя, каждая транзакция выполняется так, как если бы она была единственной операцией в системе. Результаты одной транзакции становятся видимыми для других только после ее полного завершения. Это предотвращает возникновение таких проблем, как «грязное чтение» (чтение незафиксированных данных), «неповторяющееся чтение» (чтение разных значений при повторном запросе в рамках одной транзакции) и «фантомное чтение» (появление новых строк при повторном запросе).
• Устойчивость (Durability): Это свойство гарантирует, что результаты успешно завершенной (зафиксированной) транзакции будут сохранены в базе данных навсегда и переживут любые последующие сбои системы (отключение электроэнергии, сбой оборудования и т.д.). Для обеспечения устойчивости СУБД обычно использует журналы транзакций (write-ahead logs), в которых записываются все изменения до их фактического применения к основной базе данных на диске.

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

Этапы проектирования реляционной базы данных

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

Концептуальное проектирование: Инфологическая модель

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

На этом этапе используются следующие ключевые понятия:

• Сущности (Entities): Это реальные или абстрактные объекты, о которых необходимо хранить информацию (например, «Клиент», «Товар», «Заказ»).
• Атрибуты (Attributes): Это характеристики или свойства сущностей (например, для сущности «Клиент» это могут быть «Имя», «Адрес», «Телефон»).
• Связи (Relationships): Это ассоциации между сущностями (например, связь «размещает» между сущностями «Клиент» и «Заказ»).

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

Логическое проектирование: От ER-модели к реляционной схеме

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

Центральным процессом логического проектирования является нормализация данных.

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

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

Первая, вторая и третья нормальные формы (1НФ, 2НФ, 3НФ)

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

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

Высшие нормальные формы (НФБК, 4НФ, 5НФ, 6НФ)

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

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

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

Физическое проектирование: Реализация на практике

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

На этом этапе принимаются решения о:

• Структурах хранения данных: Как данные будут физически располагаться на диске. Это включает выбор файловых групп, размеров страниц, способов размещения таблиц и индексов.
• Методах доступа к данным: Какие индексы будут созданы для ускорения поиска и сортировки данных. Правильное индексирование критически важно для производительности запросов.
• Типах данных: Конкретные типы данных СУБД, которые будут использоваться для каждого атрибута (например, INT, VARCHAR(255), DATETIME в SQL Server).
• Ограничениях целостности: Реализация правил первичных ключей, внешних ключей, уникальных ограничений, ограничений CHECK и значений по умолчанию средствами СУБД.
• Особенностях СУБД: Использование специфических функций и возможностей выбранной СУБД (например, партиционирование таблиц, кэширование, оптимизация запросов).
• Аппаратной платформе: Учет доступных ресурсов (CPU, RAM, дисковое пространство, скорость ввода/вывода) для оптимизации производительности.

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

Обеспечение целостности и безопасности данных в РБД

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

Целостность данных: Гарантия точности и непротиворечивости

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

Нарушения целостности могут быть вызваны различными факторами:

• Системные сбои: Отказы оборудования, программные ошибки СУБД или операционной системы, прерывания электропитания.
• Человеческие ошибки: Неправильный ввод данных, случайное удаление или изменение записей.
• Ошибки переноса данных: Проблемы при импорте/экспорте данных между различными системами.
• Кибератаки: Злонамеренное изменение или удаление данных с целью нарушения работы системы или получения выгоды.

Для противодействия этим угрозам в реляционных базах данных разработаны строгие правила и механизмы.

Целостность сущностей и ссылочная целостность

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

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

Нарушение ссылочной целостности может произойти в следующих случаях:

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

Для обеспечения ссылочной целостности СУБД используют ограничения внешнего ключа (FOREIGN KEY constraints), которые автоматически проверяют эти условия.

Каскадные действия для поддержания ссылочной целостности

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

Основные каскадные действия включают:

• CASCADE:
  • ON DELETE CASCADE: Если запись в родительской таблице удаляется, то все связанные записи в дочерней таблице также автоматически удаляются.
  • ON UPDATE CASCADE: Если первичный ключ записи в родительской таблице изменяется, то соответствующие значения внешних ключей во всех связанных записях дочерней таблицы также автоматически обновляются.
  • Пример: Если удалить запись о студенте из таблицы «Студенты» (ON DELETE CASCADE), то все его оценки из таблицы «Оценки» будут автоматически удалены.
• SET NULL:
  • ON DELETE SET NULL: Если запись в родительской таблице удаляется, то значения внешнего ключа в связанных записях дочерней таблицы устанавливаются в NULL. Для этого столбец внешнего ключа в дочерней таблице должен допускать NULL-значения.
  • ON UPDATE SET NULL: Если первичный ключ записи в родительской таблице изменяется, то значения внешнего ключа в связанных записях дочерней таблицы устанавливаются в NULL.
  • Пример: Если удалить запись о преподавателе, то в таблице «Курсы» поле «Преподаватель_ID» для всех курсов, которые он вел, станет NULL, если это разрешено.
• SET DEFAULT:
  • ON DELETE SET DEFAULT: При удалении записи в родительской таблице значения внешнего ключа в связанных записях дочерней таблицы устанавливаются в значение по умолчанию, если оно определено для этого столбца внешнего ключа.
  • ON UPDATE SET DEFAULT: При изменении первичного ключа в родительской таблице значения внешнего ключа в связанных записях дочерней таблицы устанавливаются в значение по умолчанию.
  • Пример: Если удалить запись о кафедре, то все студенты, прикрепленные к этой кафедре, будут автоматически прикреплены к «неопределенной» кафедре (с заданным значением по умолчанию), если такое значение установлено для внешнего ключа.
• RESTRICT или NO ACTION:
  • ON DELETE RESTRICT (или ON DELETE NO ACTION): Это действия по умолчанию в большинстве СУБД. Они запрещают (откатывают) операцию удаления записи из родительской таблицы, если существуют ссылающиеся на нее записи в дочерней таблице. Это предотвращает создание «осиротевших» записей и требует от пользователя сначала удалить или изменить зависимые записи.
  • ON UPDATE RESTRICT (или ON UPDATE NO ACTION): Аналогично, запрещают изменение первичного ключа в родительской таблице, если на него ссылаются зависимые записи.

Выбор конкретного каскадного действия зависит от бизнес-логики и требований к поведению системы при изменении данных.

Целостность домена и пользовательская целостность

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

• Целостность домена: Это правила, которые ограничивают набор допустимых значений для каждого атрибута (столбца) в таблице. Например, поле «Возраст» может быть ограничено только целыми числами от 0 до 150, а поле «Статус заказа» может принимать только значения из предопределенного списка («Новый», «В обработке», «Отправлен», «Выполнен»). Это достигается с помощью типов данных, ограничений CHECK и списков допустимых значений.
• Пользовательская целостность: Это дополнительные правила и ограничения, которые не покрываются стандартными механизмами, но являются важными для специфической бизнес-логики. Они могут быть реализованы с помощью триггеров (автоматически выполняемых процедур при определенных событиях), хранимых процедур, представлений или на уровне приложения. Например, правило, что «скидка не может превышать 20% от стоимости товара», является пользовательской целостностью.

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

Практическая реализация реляционных баз данных: СУБД Microsoft Access и SQL Server

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

Выбор СУБД: Обзор популярных решений

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

• Microsoft Access: Идеален для небольших проектов, персональных баз данных, обучения и быстрого прототипирования. Это настольная СУБД, входящая в пакет Microsoft Office, с простым графическим интерфейсом, позволяющим создавать таблицы, формы, запросы и отчеты без глубоких знаний SQL.
• Microsoft SQL Server: Корпоративное решение, предназначенное для средних и крупных предприятий. Отличается высокой производительностью, масштабируемостью, обширными возможностями по безопасности, анализу данных и интеграции с другими продуктами Microsoft.
• MySQL: Популярная СУБД с открытым исходным кодом, широко используемая для веб-приложений. Известна своей скоростью, простотой в использовании и широкой поддержкой сообщества.
• PostgreSQL: Мощная объектно-реляционная СУБД с открытым исходным кодом, обладающая богатым набором функций, высокой степенью соответствия стандартам SQL и отличной расширяемостью. Часто выбирается для критически важных систем.
• Oracle Database: Лидер среди коммерческих СУБД для крупных корпоративных систем. Обладает беспрецедентной масштабируемостью, надежностью, безопасностью и широким спектром функциональных возможностей.
• SQLite: Встраиваемая, легковесная СУБД, не требующая отдельного сервера. Идеальна для мобильных приложений, локального хранения данных и небольших десктопных программ.

Для иллюстрации практических шагов мы сфокусируемся на двух представителях: Microsoft Access как простом инструменте для новичков и Microsoft SQL Server как примере корпоративной СУБД.

Создание базы данных и таблиц

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

Создание базы данных в Microsoft Access:

1. Запустите Microsoft Access.
2. На стартовом экране выберите «Новая база данных» или «Пустая база данных».
3. В появившемся окне укажите имя файла базы данных (например, «МояУчебнаяБД.accdb») и выберите место для сохранения.
4. Нажмите «Создать». Access автоматически создаст пустую базу данных и откроет ее с новой, пустой таблицей.

Создание базы данных в Microsoft SQL Server:

1. Запустите SQL Server Management Studio (SSMS) и подключитесь к экземпляру SQL Server.
2. В «Обозревателе объектов» (Object Explorer) разверните узел «Базы данных», щелкните правой кнопкой мыши и выберите «Создать базу данных…» (New Database…).
3. В диалоговом окне «Создание базы данных» введите имя базы данных (например, «UniversityDB») и нажмите «ОК».
4. Для продвинутых пользователей можно использовать команду Transact-SQL (T-SQL) в новом окне запроса:

CREATE DATABASE UniversityDB;
GO

Создание таблиц в Microsoft Access:

1. После создания базы данных, в панели навигации слева выберите вкладку «Таблицы».
2. На вкладке «Создание» (Create) в группе «Таблицы» выберите «Конструктор таблиц» (Table Design).
3. В режиме конструктора для каждого поля:
   • Введите «Имя поля» (Field Name), например, «Студент_ID», «Имя», «Фамилия».
   • Выберите «Тип данных» (Data Type) из выпадающего списка.
   • При необходимости настройте «Свойства поля» (Field Properties) в нижней части окна (например, «Размер поля», «Формат», «Обязательное поле»).
4. Чтобы установить первичный ключ, выберите поле (или несколько полей), щелкните правой кнопкой мыши и выберите «Ключевое поле» (Primary Key).
5. Сохраните таблицу, нажав на иконку дискеты или Ctrl+S, и присвойте ей имя (например, «Студенты»).

Типы данных: Основы структурированного хранения

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

Основные типы данных в Microsoft Access:

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

• Краткий текст (Short Text/Text): Для коротких текстовых строк (до 255 символов).
• Длинный текст (Long Text/Memo): Для больших объемов текста, может хранить до 65 535 символов.
• Числовой (Number): Для хранения числовых значений (целых, дробных). Имеет несколько подтипов (Байт, Целое, Длинное целое, Одинарное с плавающей запятой, Двойное с плавающей запятой, Код репликации, Decimal).
• Дата/время (Date/Time): Для хранения значений даты и времени.
• Денежный (Currency): Для денежных значений с высокой точностью и автоматическим форматированием.
• Счётчик (AutoNumber): Автоматически генерирует уникальные последовательные или случайные числа, идеально подходит для первичных ключей.
• Логический (Yes/No): Для хранения булевых значений (Истина/Ложь, Да/Нет).
• Вложение (Attachment): Позволяет прикреплять файлы.
• Объект OLE: Для встраивания объектов OLE (например, документов Word, таблиц Excel).

Основные типы данных в SQL Server:

SQL Server предлагает более широкий и детализированный набор типов данных, отражающий его корпоративный характер:

• Числовые типы:
  • TINYINT (от 0 до 255), SMALLINT (от -32768 до 32767), INT (от -2,147,483,648 до 2,147,483,647), BIGINT (для очень больших целых чисел).
  • DECIMAL(p,s) и NUMERIC(p,s): Для точных десятичных чисел, где p — общее количество цифр, s — количество цифр после десятичной точки.
  • FLOAT и REAL: Для чисел с плавающей запятой (приблизительные значения).
  • MONEY и SMALLMONEY: Для денежных значений.
• Строковые типы:
  • CHAR(n): Строка фиксированной длины (до 8000 символов).
  • VARCHAR(n): Строка переменной длины (до 8000 символов).
  • TEXT: Для больших объемов текста (до 2 ГБ, устаревший, рекомендуется VARCHAR(MAX)).
  • NCHAR(n), NVARCHAR(n), NTEXT: Аналогичные строковые типы, но для хранения символов Unicode (многобайтовых), где n до 4000 символов. NVARCHAR(MAX) до 2 ГБ.
• Дата и время:
  • DATE: Только дата (ГГГГ-ММ-ДД).
  • TIME: Только время (ЧЧ:ММ:СС.ффф).
  • DATETIME: Дата и время (ГГГГ-ММ-ДД ЧЧ:ММ:СС.ффф, до 3,33 мс).
  • SMALLDATETIME: Дата и время (ГГГГ-ММ-ДД ЧЧ:ММ:СС, до 1 минуты).
  • DATETIME2: Более точный тип DATETIME (до 100 нс).
  • DATETIMEOFFSET: DATETIME2 с информацией о часовом поясе.
• Бинарные типы:
  • BINARY(n), VARBINARY(n), IMAGE: Для хранения двоичных данных, таких как изображения, файлы. VARBINARY(MAX) до 2 ГБ.
• Другие типы:
  • BIT: Логический тип (0 или 1).
  • UNIQUEIDENTIFIER: Глобально уникальный идентификатор (GUID).
  • XML: Для хранения XML-документов.
  • GEOMETRY, GEOGRAPHY: Для пространственных данных.

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

Язык SQL: Манипулирование данными и запросы

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

Категории SQL-запросов: DDL, DML, DCL, TCL

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

• DDL (Data Definition Language) — Язык Определения Данных:
  • Используется для создания, изменения и удаления структуры базы данных и ее объектов (таблиц, индексов, представлений, хранимых процедур и т.д.).
  • Основные операторы:
    • CREATE: Для создания объектов (например, CREATE DATABASE, CREATE TABLE, CREATE INDEX).
    • ALTER: Для изменения структуры существующих объектов (например, ALTER TABLE ADD COLUMN).
    • DROP: Для удаления объектов (например, DROP TABLE, DROP DATABASE).
    • TRUNCATE: Быстрое удаление всех строк из таблицы, сброс счетчиков.
    • RENAME: Переименование объектов.
• DML (Data Manipulation Language) — Язык Манипулирования Данными:
  • Используется для работы с самими данными, хранящимися в таблицах. Это наиболее часто используемая часть SQL.
  • Основные операторы:
    • SELECT: Для извлечения данных из базы данных.
    • INSERT: Для добавления новых записей (строк) в таблицу.
    • UPDATE: Для изменения существующих записей в таблице.
    • DELETE: Для удаления записей из таблицы.
• DCL (Data Control Language) — Язык Контроля Данных:
  • Используется для управления правами доступа пользователей к данным и объектам базы данных.
  • Основные операторы:
    • GRANT: Для предоставления прав доступа (например, GRANT SELECT ON table_name TO user_name).
    • REVOKE: Для отзыва ранее предоставленных прав.
    • DENY: Для явного запрета прав.
• TCL (Transaction Control Language) — Язык Управления Транзакциями:
  • Используется для управления транзакциями, обеспечивая свойства ACID.
  • Основные операторы:
    • COMMIT: Сохраняет все изменения, сделанные в рамках текущей транзакции, в базе данных.
    • ROLLBACK: Отменяет все изменения, сделанные в рамках текущей транзакции, возвращая базу данных в состояние до ее начала.
    • SAVEPOINT: Устанавливает точку сохранения внутри транзакции, к которой можно откатиться.

Основные операторы DML: SELECT, INSERT, UPDATE, DELETE

Четыре оператора DML являются краеугольным камнем для любого взаимодействия с данными.

• SELECT — Извлечение данных:
  • Это самый мощный и часто используемый оператор. Он позволяет выбрать данные из одной или нескольких таблиц в соответствии с заданными критериями.
  • Синтаксис:

  SELECT [DISTINCT] column1, column2, ...
  FROM table_name
  [JOIN table_name2 ON join_condition]
  [WHERE condition]
  [GROUP BY column_name(s)]
  [HAVING condition]
  [ORDER BY column_name(s) [ASC|DESC]];
  

  • Пример: Извлечь имена и фамилии всех студентов, родившихся после 2000 года, отсортированных по фамилии:

  SELECT Имя, Фамилия
  FROM Студенты
  WHERE ДатаРождения > '2000-01-01'
  ORDER BY Фамилия ASC;
  

• INSERT — Добавление новых данных:
  • Оператор INSERT используется для добавления одной или нескольких новых строк в таблицу.
  • Синтаксис:

  INSERT INTO table_name (column1, column2, ...)
  VALUES (value1, value2, ...);
  

  • Пример: Добавить нового студента:

  INSERT INTO Студенты (Студент_ID, Имя, Фамилия, ДатаРождения)
  VALUES (104, 'Олег', 'Иванов', '2001-05-15');
  

• UPDATE — Изменение существующих данных:
  • Оператор UPDATE позволяет изменять значения в существующих строках таблицы.
  • Важно: Всегда используйте предложение WHERE с UPDATE, чтобы не изменить все записи в таблице.
  • Синтаксис:

  UPDATE table_name
  SET column1 = new_value1, column2 = new_value2, ...
  WHERE condition;
  

  • Пример: Изменить фамилию студента с Студент_ID = 101 на «Петрова-Смирнова»:

  UPDATE Студенты
  SET Фамилия = 'Петрова-Смирнова'
  WHERE Студент_ID = 101;
  

• DELETE — Удаление данных:
  • Оператор DELETE используется для удаления одной или нескольких строк из таблицы.
  • Важно: Как и в случае с UPDATE, крайне важно использовать предложение WHERE, чтобы избежать удаления всех записей в таблице.
  • Синтаксис:

  DELETE FROM table_name
  WHERE condition;
  

  • Пример: Удалить студента с Студент_ID = 103:

  DELETE FROM Студенты
  WHERE Студент_ID = 103;
  

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

Помимо прямых SQL-запросов, для выполнения операций DML часто используются хранимые процедуры (Stored Procedures). Это предварительно скомпилированные коллекции SQL-операторов, которые хранятся в базе данных и могут быть вызваны по имени.

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

• Производительность: СУБД компилирует процедуру только один раз при первом вызове. Последующие вызовы выполняются быстрее, так как не требуется повторная компиляция.
• Безопасность: Пользователям можно предоставить права на выполнение хранимых процедур, не давая прямого доступа к базовым таблицам. Это позволяет контролировать, какие данные они могут изменять или просматривать.
• Сокращение сетевого трафика: Вместо отправки нескольких SQL-запросов, приложение отправляет только один вызов хранимой процедуры.
• Повторное использование кода: Однажды написанная процедура может использоваться множеством приложений.
• Централизация бизнес-логики: Сложная логика может быть инкапсулирована в процедурах, что упрощает ее изменение и поддержку.

Пример создания и вызова хранимой процедуры (SQL Server):

-- Создание хранимой процедуры для добавления студента
CREATE PROCEDURE AddStudent
    @StudentID INT,
    @FirstName NVARCHAR(50),
    @LastName NVARCHAR(50),
    @BirthDate DATE
AS
BEGIN
    INSERT INTO Студенты (Студент_ID, Имя, Фамилия, ДатаРождения)
    VALUES (@StudentID, @FirstName, @LastName, @BirthDate);
END;
GO

-- Вызов хранимой процедуры
EXEC AddStudent 105, 'Виктор', 'Комаров', '2002-11-20';

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

Разработка пользовательских интерфейсов и отчетов

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

Создание форм в Microsoft Access

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

Существует несколько методов создания форм в Access:

1. Мастер форм (Form Wizard): Это самый простой способ создания формы. Мастер пошагово проведет пользователя через процесс, предлагая выбрать таблицу или запрос, поля для включения в форму, макет (столбцы, ленточный, табличный, выровненный) и стиль. Это отличный вариант для быстрого создания стандартных форм.
2. Средство форм (Form Tool): На вкладке «Создание» (Create) можно просто нажать «Форма» (Form), и Access автоматически создаст новую форму, отображающую все поля из текущей выбранной таблицы или запроса. Это удобно для быстрого просмотра данных.
3. Пустая форма (Blank Form): Если требуется полный контроль над дизайном, можно начать с пустой формы. В режиме «Конструктора форм» (Form Design View) можно вручную добавлять элементы управления (текстовые поля, кнопки, списки), связывать их с полями таблицы или запроса, а также настраивать их внешний вид и поведение.
4. Конструктор форм (Form Design): Этот режим предоставляет максимальную гибкость для создания сложных и кастомизированных форм. Здесь можно точно расположить элементы управления, добавить графику, кнопки с макросами или VBA-кодом, а также настроить события, реагирующие на действия пользователя.

Формы могут быть:

• Связанными (Bound Forms): Напрямую связаны с источником данных (таблицей или запросом). Изменения, внесенные в форму, автоматически отражаются в базовых данных.
• Несвязанными (Unbound Forms): Используются для выполнения определенных действий, отображения информации, не связанной напрямую с конкретной записью, или для создания диалоговых окон. Элементы управления на таких формах не привязаны к полям таблицы.

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

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

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

Access предоставляет несколько способов для создания отчетов:

1. Средство отчетов (Report Tool): Подобно средству форм, позволяет быстро создать простой отчет, отображающий все поля из выбранной таблицы или запроса.
2. Мастер отчетов (Report Wizard): Предлагает пошаговый процесс создания отчета, позволяя выбрать поля, группировать данные, сортировать их, вычислять итоги и выбирать макет. Это отличный инструмент для создания структурированных отчетов.
3. Конструктор отчетов (Report Design View): Дает полный контроль над дизайном отчета. В этом режиме можно добавлять заголовки, колонтитулы, группировать данные по различным критериям, использовать выражения для вычислений, добавлять графики и другие элементы форматирования.
4. Пустой отчет (Blank Report): Позволяет начать с чистого листа и полностью настроить отчет, добавляя элементы управления и привязывая их к данным.

Отчеты могут быть настроены для вывода данных в различных форматах:

• Печатные формы: Для создания документов, готовых к печати.
• Электронные форматы: Экспорт отчетов в PDF, Microsoft Excel, RTF (Rich Text Format), HTML, а также в различные текстовые форматы (TXT, CSV, TAB, ASC) и XML. Это позволяет легко обмениваться информацией и интегрировать ее с другими системами.

Примеры использования отчетов:

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

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

Актуальные тенденции и вызовы в области баз данных: Взгляд в будущее

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

Эволюция архитектур: От монолитов к облачным и бессерверным решениям

Традиционные «монолитные» реляционные СУБД, устанавливаемые на выделенные серверы, постепенно уступают место более гибким и масштабируемым архитектурам, особенно в контексте облачных вычислений:

• Cloud-native базы данных: Это СУБД, которые изначально проектируются и оптимизируются для работы в облачной среде. Они используют преимущества облачной инфраструктуры, такие как автоматическое масштабирование, высокая доступность, отказоустойчивость и управление ресурсами «по требованию». Примеры включают Amazon Aurora, Google Cloud Spanner, Azure Cosmos DB. Их основное преимущество — возможность быстрого развертывания, автоматического управления и оплаты только за фактически используемые ресурсы.
• Serverless-архитектуры: Следующий шаг в эволюции облачных БД, где разработчику не нужно беспокоиться о серверах вообще. Провайдер облачных услуг полностью управляет инфраструктурой, автоматически выделяя ресурсы по мере необходимости и масштабируя их до нуля в периоды низкой активности. Это позволяет значительно сократить операционные расходы и упростить администрирование СУБД, позволяя разработчикам сосредоточиться на бизнес-логике. Примером является Amazon DynamoDB в serverless режиме.

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

Новые модели данных: NoSQL, мультимодельные, графовые и векторные СУБД

Реляционные базы данных отлично подходят для структурированных данных, но не всегда эффективны для работы с огромными объемами неструктурированной информации или для задач, требующих специфических моделей связей. Это привело к появлению и широкому распространению NoSQL-систем (Not only SQL):

• NoSQL-системы: Разработаны для работы с большими объемами неструктурированных или полуструктурированных данных. Они предлагают высокую горизонтальную масштабируемость, отказоустойчивость и скорость, часто жертвуя некоторыми аспектами ACID-транзакций в пользу модели BASE (Basically Available, Soft state, Eventually consistent). Примеры:
  • Документоориентированные БД (MongoDB, Couchbase): Хранят данные в виде JSON-подобных документов.
  • Ключ-значение хранилища (Redis, Amazon DynamoDB): Простейшая модель, где данные хранятся как пары ключ-значение.
  • Колоночные БД (Cassandra, HBase): Оптимизированы для агрегации больших объемов данных по столбцам.
  • Графовые БД (Neo4j, ArangoDB): Идеальны для хранения и анализа сильно связанных данных, где важны отношения между сущностями (например, социальные сети, рекомендательные системы, обнаружение мошенничества).
• Мультимодельные СУБД: Это системы, которые поддерживают несколько моделей данных (например, реляционную, документоориентированную, графовую) в рамках одной СУБД. Это позволяет разработчикам выбирать наиболее подходящую модель для конкретной части данных, не разворачивая несколько отдельных баз данных. Примеры: ArangoDB, MarkLogic.
• Векторные хранилища: Стали приоритетными в 2024 году, особенно в контексте развития искусственного интеллекта (ИИ). Они оптимизированы для хранения и поиска высокоразмерных векторных представлений данных (эмбеддингов), используемых в алгоритмах машинного обучения для поиска сходства, кластеризации и работы с генеративными моделями.

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

Интеграция с искусственным интеллектом и машинным обучением

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

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

Таблица 2. Сравнение различных моделей баз данных

Характеристика	Реляционные БД (SQL)	NoSQL (документные/ключ-значение)	Графовые БД
Модель данных	Таблицы, строки, столбцы	Документы, пары ключ-значение	Узлы, ребра, свойства
Схема	Строгая, предопределенная	Гибкая, динамическая	Гибкая
Масштабируемость	Вертикальная (преимущественно), горизонтальная (сложно)	Горизонтальная (легко)	Горизонтальная (специфично)
ACID	Полная поддержка	Частичная (BASE)	Зависит от реализации
Применение	Транзакции, структурированные данные	Big Data, неструктурированные данные, веб	Связанные данные, сети, рекомендации
Примеры	PostgreSQL, MySQL, SQL Server	MongoDB, Cassandra, Redis	Neo4j, ArangoDB

Вызовы управления большими данными: Безопасность и эффективность

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

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

• Шифрование: Фундаментальный метод защиты данных. Применяется на всех этапах: во время сбора, хранения (Encryption at Rest) и передачи (Encryption in Transit, например, через VPN). Используются симметричные, асимметричные алгоритмы и хеширование.
• Управление доступом: Строгое определение прав доступа пользователей и систем на основе принципа минимальных привилегий (Role-Based Access Control, RBAC). Включает двухфакторную аутентификацию, аудит доступа и мониторинг.
• Маскирование и анонимизация данных: Технологии ��ля скрытия конфиденциальной информации в непроизводственных средах или при обмене данными, сохраняя при этом их аналитическую ценность.
• Аудит и мониторинг: Постоянный контроль всех операций с данными и действий пользователей для выявления аномалий и потенциальных угроз в реальном времени. Регулярные аудиты безопасности.
• Физическая безопасность: Контроль доступа к серверным помещениям, защита оборудования.
• Системы предотвращения утечек данных (DLP): Обнаружение и предотвращение передачи конфиденциальной информации за пределы контролируемой среды.
• Безопасность распределенных баз данных: Особые вызовы, связанные с защитой данных, находящихся на разных узлах и передаваемых между ними.

Для повышения эффективности хранения и обработки больших объемов данных применяются следующие подходы:

• Распределенные файловые системы (например, HDFS): Стандарт для распределенного хранения больших файлов с высокой отказоустойчивостью и оптимизацией для потокового доступа.
• Data Lakes: Единые хранилища для слабоструктурированных и неструктурированных данных (логов, медиафайлов, IoT-данных), масштабируемые до петабайтов и тысяч серверов. Они экономичны для хранения и поддерживают различные форматы.
• NoSQL-системы: Как уже упоминалось, они изначально спроектированы для горизонтальной масштабируемости и высокой производительности при работе с неструктурированными данными.
• Горизонтальная масштабируемость (Horizontal Scalability): Ключевой принцип, подразумевающий добавление новых узлов (серверов) для увеличения производительности и емкости, вместо увеличения мощности одного сервера (вертикальная масштабируемость).
• Сжатие и дедупликация данных: Методы оптимизации дискового пространства за счет уменьшения размера хранимых данных и удаления дубликатов.
• Кэширование: Хранение часто используемых данных в быстрой памяти (RAM) для ускорения доступа.
• Специализированные аналитические базы данных: Такие как ClickHouse, Greenplum, Vertica, или PostgreSQL с расширением Citus, оптимизированные для выполнения сложных аналитических запросов на больших объемах данных.
• In-Memory технологии: Хранение и обработка данных непосредственно в оперативной памяти, что значительно ускоряет выполнение запросов и аналитических операций (например, SQL Server In-Memory OLTP).

Оптимизация администрирования РБД: Снижение затрат времени и ресурсов

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

Основные трудозатратные аспекты администрирования РБД включают:

• Установка и конфигурация: Выбор оптимальной СУБД, настройка параметров хранения, прав доступа, производительности и безопасности. Этот этап требует глубоких знаний архитектуры СУБД.
• Мониторинг и оптимизация производительности: Постоянное отслеживание работы базы данных, анализ метрик (загрузка CPU, ввода/вывода, использование памяти), выявление «узких мест» (долго выполняющиеся запросы, отсутствующие индексы, блокировки), тонкая настройка SQL-запросов и конфигурации сервера. Это непрерывный и часто сложный процесс.
• Резервное копирование и восстановление: Разработка и регулярное выполнение планов резервного копирования, тестирование процедур восстановления. Это критически важная, но рутинная задача, требующая внимания и автоматизации.
• Управление безопасностью: Настройка и поддержание системы прав доступа пользователей, защита от уязвимостей, управление учетными записями, реагирование на инциденты безопасности.
• Управление версиями и обновления: Планирование и выполнение обновлений СУБД, установка патчей, миграция данных на новые версии, что часто связано с простоями системы.
• Миграция данных: Перенос баз данных и приложений между тестовыми и продуктивными средами, а также между разными версиями или типами СУБД.
• Устранение неполадок (Troubleshooting): Диагностика и исправление сбоев, ошибок и проблем с производительностью, что может быть крайне сложным и требовать глубоких аналитических навыков.
• Поддержание целостности данных: Обеспечение постоянной согласованности и корректности данных, что может включать сложные процедуры валидации и исправления.
• Сложность схем данных: Для больших систем с сотнями таблиц и сложными связями разработка, отладка и оптимизация SQL-запросов становятся значительно более трудоемкими.
• Простои для обслуживания: Некоторые операции, такие как перестроение индексов или сокращение баз данных (хотя последнее считается плохой практикой), могут вызывать значительные простои, если не спланированы и не выполнены эффективно.
• Отсутствие автоматизации: Без специализированных инструментов автоматизации (например, Ansible, Chef, Puppet, или кастомных скриптов) многие из этих задач выполняются вручную, что увеличивает время, затраты и вероятность ошибок.

Решение этих вызовов лежит в комплексной автоматизации, использовании управляемых облачных сервисов (Managed Database Services), применении DevOps-практик для баз данных (Database DevOps) и инвестициях в инструменты мониторинга и оптимизации, а также в повышении квалификации специалистов.

Заключение

Путешествие в мир реляционных баз данных — это погружение в область, где логика и структура становятся основой для управления информацией. Мы проследили путь от фундаментальных принципов, заложенных в реляционной модели, до тонкостей проектирования, обеспечения целостности и практической реализации с использованием таких инструментов, как Microsoft Access и SQL Server. Подробно рассмотрены базовые и высшие нормальные формы, механизмы ACID и каскадные действия, что составляет академическую полноту понимания.

Особое внимание уделено динамичной эволюции сферы баз данных. Становится очевидным, что классические реляционные решения, несмотря на свою надежность, не всегда достаточны для решения всех задач в условиях экспоненциального роста Big Data, появления неструктурированных данных и требований к гипермасштабируемости. Современные тенденции, такие как Cloud-native и Serverless архитектуры, многообразие NoSQL-систем, графовые и векторные хранилища, а также глубокая интеграция с искусственным интеллектом, указывают на формирование нового ландшафта управления данными.

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

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

1. Бекаревич Ю.Б., Пушкина Н.В. Самоучитель Microsoft Access 2003. СПб: изд. BHV, 2004. 752 с.
2. Карпов Б. Microsoft Access 2000: справочник. СПб: Питер, 2000. 416 с.
3. Кауфельд Дж. Access 2000 для Windows для «чайников». Пер. с англ. М.: Вильямс, 2003. 336 с.
4. Праг К., Ирвин М. Access 2002. Библия пользователя. Пер. с англ. М.: Вильямс, 2004. 1216 с.
5. Стоцкий Ю. Самоучитель Office 2000. СПб: Питер, 1999. 576 с.
6. Проектирование реляционных баз данных: основные принципы. URL: https://habr.com/ru/companies/otus/articles/731118/ (дата обращения: 15.10.2025).
7. Что такое реляционная база данных? Amazon Web Services (AWS). URL: https://aws.amazon.com/ru/relational-databases/ (дата обращения: 15.10.2025).
8. Реляционные базы данных: основные принципы, структура и характеристики. Yandex Cloud — Документация. URL: https://cloud.yandex.ru/docs/managed-postgresql/concepts/relational-database (дата обращения: 15.10.2025).
9. Реляционные базы данных. Рег. облако. URL: https://reg.ru/cloud-databases/articles/relational-databases (дата обращения: 15.10.2025).
10. Реляционные базы данных: что это и как они работают. Cloud.ru. URL: https://cloud.ru/blog/relacionnye-bazy-dannyh-chto-eto-i-kak-oni-rabotayut (дата обращения: 15.10.2025).
11. Что такое реляционная база данных. Академия Selectel. URL: https://selectel.ru/blog/relational-database/ (дата обращения: 15.10.2025).
12. Тенденции развития баз данных: что важно знать. DB Serv. URL: https://dbserv.ru/blog/tendencii-razvitiya-baz-dannyh-chto-vazhno-znat (дата обращения: 15.10.2025).
13. Целостность сущностей. URL: https://citforum.ru/database/introd/8_2.shtml (дата обращения: 15.10.2025).
14. Ссылочная целостность. Википедия. URL: https://ru.wikipedia.org/wiki/%D0%A1%D1%81%D1%8B%D0%BB%D0%BE%D1%87%D0%BD%D0%B0%D1%8F_%D1%86%D0%B5%D0%BB%D0%BE%D1%81%D1%82%D0%BD%D0%BE%D1%81%D1%82%D1%8C (дата обращения: 15.10.2025).
15. Этапы проектирования реляционной базы данных. URL: https://www.intuit.ru/studies/courses/106/106/lecture/2927?page=2 (дата обращения: 15.10.2025).
16. Что такое ссылочная целостность. Термины и определения в области кибербезопасности. VPN Unlimited. URL: https://www.vpnunlimited.com/ru/blog/what-is-referential-integrity (дата обращения: 15.10.2025).
17. Целостность данных в базах данных: что это и зачем нужно. Staffcop. URL: https://www.staffcop.ru/blog/celostnost-dannykh-v-bazakh-dannykh/ (дата обращения: 15.10.2025).
18. Ограничения целостности в реляционной модели данных. URL: https://www.citforum.ru/database/data_integrity/2.shtml (дата обращения: 15.10.2025).
19. Целостность данных (Data integrity). Loginom Wiki. URL: https://loginom.ru/wiki/celostnost-dannyh (дата обращения: 15.10.2025).
20. Тенденции развития баз данных: обзор за 2024 год и взгляд в будущее. itWeek. URL: https://www.itweek.ru/db/article/detail.php?ID=228023 (дата обращения: 15.10.2025).
21. Нормальная форма. Википедия. URL: https://ru.wikipedia.org/wiki/%D0%9D%D0%BE%D1%80%D0%BC%D0%B0%D0%BB%D1%8C%D0%9D%D0%B0%D1%8F_%D0%A4%D0%BE%D1%80%D0%BC%D0%B0 (дата обращения: 15.10.2025).
22. Что такое нормализация базы данных? Академия доступного IT образования. URL: https://itproger.com/blog/chto-takoe-normalizacia-bazy-dannyh (дата обращения: 15.10.2025).
23. Введение в системы управления базами данных. Глава 3. Целостность реляционных данных. CITForum.ru. URL: https://citforum.ru/database/introd/3.shtml (дата обращения: 15.10.2025).
24. Реляционная база данных: принцип работы, перспективы использования. DECO systems. URL: https://decosystems.ru/relational-database (дата обращения: 15.10.2025).
25. Целостность данных. Шпаргалка для DevOps-инженера. DEVOPSGU.RU. URL: https://devopsgu.ru/celostnost-dannykh (дата обращения: 15.10.2025).
26. Базовые понятия реляционных баз данных. URL: https://citforum.ru/database/introd/4_1.shtml (дата обращения: 15.10.2025).
27. Ссылочная целостность является важной для баз данных. CITForum.ru. URL: https://citforum.ru/database/blaha/referential_integrity.shtml (дата обращения: 15.10.2025).
28. Ссылочная целостность. AppMaster. URL: https://appmaster.io/ru/blog/ssylochnaia-tselostnost (дата обращения: 15.10.2025).
29. Реляционные базы данных. Информатика. Фоксфорд Учебник. URL: https://foxford.ru/wiki/informatika/relyatsionnye-bazy-dannykh (дата обращения: 15.10.2025).
30. Реляционные базы данных. Нормализация. METANIT.COM. URL: https://metanit.com/sql/database/2.2.php (дата обращения: 15.10.2025).
31. Целостность сущностей. URL: https://citforum.ru/database/db_design/ch16_9.shtml (дата обращения: 15.10.2025).
32. Новые тенденции в построении баз данных: взгляд ITSource. URL: https://itsource.ru/novosti/novye-tendentsii-v-postroenii-baz-dannykh-vzglyad-itsource/ (дата обращения: 15.10.2025).
33. Целостность данных в базе данных: почему это важно. Astera Software. URL: https://www.astera.com/ru/resources/data-integrity-in-database/ (дата обращения: 15.10.2025).
34. Новые горизонты баз данных: 8 тенденций в управлении информацией. Habr. URL: https://habr.com/ru/companies/otus/articles/800589/ (дата обращения: 15.10.2025).
35. Нормализация отношений. Шесть нормальных форм. Habr. URL: https://habr.com/ru/articles/256953/ (дата обращения: 15.10.2025).
36. Примеры и принципы нормализации реляционных баз данных (БД). DecoSystems. URL: https://decosystems.ru/normalizaciya-baz-dannyh (дата обращения: 15.10.2025).
37. БД_ВТ: Лекция 5. Целостная составляющая реляционной модели данных. URL: https://e.sfu-kras.ru/bitstream/handle/2311/2472/bd_vt_lekcia_5.pdf?sequence=6&isAllowed=y (дата обращения: 15.10.2025).
38. Базы данных: современные тенденции в области баз данных и их значимость для различных сфер деятельности. КиберЛенинка. URL: https://cyberleninka.ru/article/n/bazy-dannyh-sovremennye-tendentsii-v-oblasti-baz-dannyh-i-ih-znachimost-dlya-razlichnyh-sfer-deyatelnosti (дата обращения: 15.10.2025).
39. Глава 17. Принципы проектирования реляционных баз данных. URL: https://www.intuit.ru/studies/courses/40/40/lecture/1004?page=1 (дата обращения: 15.10.2025).
40. Реляционная база данных: принцип работы, перспективы использования. GeekBrains. URL: https://gb.ru/blog/relational-database/ (дата обращения: 15.10.2025).
41. Реляционные базы данных: структура и применение в практике. FoxmindEd. URL: https://foxminded.com.ua/ru/sql/relational-databases/ (дата обращения: 15.10.2025).
42. Что такое система управления реляционными базами данных? Microsoft Azure. URL: https://azure.microsoft.com/ru-ru/resources/cloud-computing-dictionary/what-is-a-relational-database-management-system (дата обращения: 15.10.2025).
43. Базы данных. БНТУ. URL: https://dl.bntu.by/pluginfile.php/228187/mod_resource/content/1/4.pdf (дата обращения: 15.10.2025).
44. Проектирование баз данных. Википедия. 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 (дата обращения: 15.10.2025).
45. Типы данных в MS Access. URL: https://accessinfo.ru/ms-access/tipy-dannykh-v-ms-access.html (дата обращения: 15.10.2025).
46. Типы данных в SQL. Ravesli. URL: https://ravesli.com/uroki-po-sql/176-tipy-dannyh-v-sql (дата обращения: 15.10.2025).
47. Типы данных в Microsoft Access. Назначение, примеры. URL: https://office-guru.ru/access/tipy-dannyh-v-microsoft-access.html (дата обращения: 15.10.2025).
48. Создание форм в Microsoft Access. URL: https://accessinfo.ru/ms-access/sozdanie-form-v-microsoft-access.html (дата обращения: 15.10.2025).
49. Типы данных (Transact-SQL). SQL Server. Microsoft Learn. URL: https://learn.microsoft.com/ru-ru/sql/t-sql/data-types/data-types-transact-sql?view=sql-server-ver16 (дата обращения: 15.10.2025).
50. Создание формы в Access. Служба поддержки Майкрософт. URL: https://support.microsoft.com/ru-ru/office/%D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%BD%D0%B8%D0%B5-%D1%84%D0%BE%D1%80%D0%BC%D1%8B-%D0%B2-access-5ac3d4d4-20ec-4591-95c4-42171176b6b7 (дата обращения: 15.10.2025).
51. Создание базы данных. SQL Server. Microsoft Learn. URL: https://learn.microsoft.com/ru-ru/sql/relational-databases/databases/create-a-database?view=sql-server-ver16 (дата обращения: 15.10.2025).
52. Целостность данных в Microsoft Access. URL: https://accessinfo.ru/ms-access/celostnost-dannykh-v-microsoft-access.html (дата обращения: 15.10.2025).
53. Базы данных Access: функции, режимы работы и элементы. GeekBrains. URL: https://gb.ru/blog/ms-access-funkcii/ (дата обращения: 15.10.2025).
54. Как создать базу данных в SQL Server. Q&A Хекслет. URL: https://ru.hexlet.io/qna/sql/kak-sozdat-bazu-dannyh-v-sql-server-c38a4d46-a457-4171-897b-871d87e0b51e (дата обращения: 15.10.2025).
55. Создание форм в программе Microsoft Access. Сила знаний. URL: https://silaznaniy.ru/sozdanie-form-v-programme-microsoft-access/ (дата обращения: 15.10.2025).
56. Создание форм в Access. Компьютерапия. URL: https://computerapy.ru/sozdanie-form-v-access/ (дата обращения: 15.10.2025).
57. Mastering SQL: How to Use SELECT, INSERT, UPDATE, and DELETE Commands. Secoda. URL: https://www.secoda.com/blog/sql-select-insert-update-delete (дата обращения: 15.10.2025).
58. Типы данных SQL: какие бывают и как с ними работать. GeekBrains. URL: https://gb.ru/blog/sql-data-types/ (дата обращения: 15.10.2025).
59. Типы данных для баз данных Access для настольных компьютеров. Microsoft Support. URL: https://support.microsoft.com/ru-ru/office/%D1%82%D0%B8%D0%BF%D1%8B-%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D0%B5-%D0%B4%D0%BB%D1%8F-%D0%B1%D0%B0%D0%B7-%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85-access-%D0%B4%D0%BB%D1%8F-%D0%BD%D0%B0%D1%81%D1%82%D0%BE%D0%BB%D1%8C%D0%BD%D1%8B%D1%85-%D0%BA%D0%BE%D0%BC%D0%BF%D1%8C%D1%8E%D1%82%D0%B5%D1%80%D0%BE%D0%B2-b7e67f08-b80e-43f7-a36c-947f63124508 (дата обращения: 15.10.2025).
60. Создание запроса, формы или отчета в Access. Служба поддержки Майкрософт. URL: https://support.microsoft.com/ru-ru/office/%D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%BD%D0%B8%D0%B5-%D0%B7%D0%B0%D0%BF%D1%80%D0%BE%D1%81%D0%B0-%D1%84%D0%BE%D1%80%D0%BC%D1%8B-%D0%B8%D0%BB%D0%B8-%D0%BE%D1%82%D1%87%D0%B5%D1%82%D0%B0-%D0%B2-access-5ac3d4d4-20ec-4591-95c4-42171176b6b7 (дата обращения: 15.10.2025).
61. Манипуляции с данными: SELECT, INSERT, UPDATE, DELETE. URL: https://www.mysql.ru/docs/mysql-3.23/manual.html#Manipulating_data (дата обращения: 15.10.2025).
62. Руководство по созданию отчетов. Служба поддержки Майкрософт. URL: https://support.microsoft.com/ru-ru/office/%D1%80%D1%83%D0%BA%D0%BE%D0%B2%D0%BE%D0%B4%D1%81%D1%82%D0%B2%D0%BE-%D0%BF%D0%BE-%D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%BD%D0%B8%D1%8E-%D0%BE%D1%82%D1%87%D0%B5%D1%82%D0%BE%D0%B2-a25a3a79-1ecf-4e08-9635-4ae5a86a605f (дата обращения: 15.10.2025).
63. Формы. Служба поддержки Майкрософт. URL: https://support.microsoft.com/ru-ru/office/%D1%84%D0%BE%D1%80%D0%BC%D1%8B-73602d84-180b-48ae-a212-04e8d89a444f (дата обращения: 15.10.2025).
64. MS SQL Server и T-SQL. Типы данных SQL. METANIT.COM. URL: https://metanit.com/sql/sqlserver/2.1.php (дата обращения: 15.10.2025).
65. Типы данных в SQL с примерами — числовые, строковые, логические. Блог IT Resume. URL: https://itresume.ru/blog/sql-data-types (дата обращения: 15.10.2025).
66. MS SQL Server и T-SQL. Создание и удаление базы данных. METANIT.COM. URL: https://metanit.com/sql/sqlserver/2.3.php (дата обращения: 15.10.2025).
67. Как создать форму с помощью КОНСТРУКТОРА в базе данных ACCESS. YouTube. URL: https://www.youtube.com/watch?v=kYV3-R9yYI4 (дата обращения: 15.10.2025).
68. MS Access – разработка отчетов, обработка данных в режиме формы. ИнфоБлог. URL: https://infoblog.org.ua/ms-access-razrabotka-otchetov-obrabotka-dannyh-v-rezhime-formy/ (дата обращения: 15.10.2025).
69. Создание отчетов различными способами в СУБД Microsoft Access. IT Black. URL: https://it-black.ru/sozdanie-otchetov-razlichnymi-sposobami-v-subd-microsoft-access/ (дата обращения: 15.10.2025).
70. Ms Access — Типы данных. Tilda. URL: https://tilda.cc/ru/lp/access-tutorial/ms-access-data-types/ (дата обращения: 15.10.2025).
71. Разработка отчетов. Без названия. URL: https://www.nsu.ru/education/teach/materials/sistemy-upravleniya-bazami-dannykh/Razrabotka_otchetov.html (дата обращения: 15.10.2025).
72. SQL Basics: SELECT, INSERT, UPDATE & DELETE. YouTube. URL: https://www.youtube.com/watch?v=F3_s8X4j30k (дата обращения: 15.10.2025).
73. Пошаговое создание таблиц в базе данных Access. URL: https://accessinfo.ru/ms-access/poshagovoe-sozdanie-tablic-v-baze-dannyh-access.html (дата обращения: 15.10.2025).
74. Создание таблицы и добавление полей. Служба поддержки Майкрософт. URL: https://support.microsoft.com/ru-ru/office/%D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%BD%D0%B8%D0%B5-%D1%82%D0%B0%D0%B1%D0%BB%D0%B8%D1%86%D1%8B-%D0%B8-%D0%B4%D0%BE%D0%B1%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5-%D0%BF%D0%BE%D0%BB%D0%B5%D0%B9-865671d4-0723-44b4-a4f6-5e01614f6b21 (дата обращения: 15.10.2025).
75. Основы работы с базами SQL. Otus. URL: https://otus.ru/journal/osnovy-raboty-s-bazami-sql/ (дата обращения: 15.10.2025).
76. Creating a Database in Microsoft SQL Server (CREATE DATABASE) – A Video Tutorial for Beginners. YouTube. URL: https://www.youtube.com/watch?v=XW9_3i2p-iY (дата обращения: 15.10.2025).
77. Как сделать таблицы в базе данных Microsoft Access 2016. YouTube. URL: https://www.youtube.com/watch?v=tJ7jNtsKx9E (дата обращения: 15.10.2025).
78. SQL Server. Работа с SELECT. Операции удаления, вставки и обновления данных. URL: https://ruseller.com/lessons/l19316/lesson/sqlserver_select_insert_update_delete/ (дата обращения: 15.10.2025).
79. MS Access — создание таблиц. CoderLessons.com. URL: https://coderlessons.com/articles/ms-access/ms-access-sozdanie-tablits (дата обращения: 15.10.2025).
80. Создание таблиц и добавление записей в Microsoft Access. YouTube. URL: https://www.youtube.com/watch?v=yYn9h2gK96I (дата обращения: 15.10.2025).
81. SQL-запросы: основные команды для управления базами данных. Skillbox. URL: https://skillbox.ru/media/code/sql-zaprosy-osnovnye-komandy-dlya-upravleniya-bazami-dannykh/ (дата обращения: 15.10.2025).
82. SQL-запросы: основные операторы, виды, синтаксис, написание, создание базы данных, примеры простых и сложных команд. Skypro. URL: https://sky.pro/media/sql-zaprosy/ (дата обращения: 15.10.2025).
83. SQL шпаргалка insert select update delete. URL: https://programka.com.ua/shparhalka-sql-insert-select-update-delete.php (дата обращения: 15.10.2025).
84. Примеры SELECT (Transact-SQL). SQL Server. Microsoft Learn. URL: https://learn.microsoft.com/ru-ru/sql/t-sql/queries/select-examples-transact-sql?view=sql-server-ver16 (дата обращения: 15.10.2025).
85. Целостность данных. URL: https://infobig.ru/articles/celostnost-dannyh.html (дата обращения: 15.10.2025).
86. Разработка интерфейса пользователя базы данных. URL: https://www.ugatu.su/fileadmin/userupload/education/library/Izdatelstvo_UGATU/Uchebnye_posobiya/2009/PiG_PI_Razrabotka_interfeysa_polzovatelya_bazy_dannykh.pdf (дата обращения: 15.10.2025).
87. Обеспечение целостности данных. URL: https://accessinfo.ru/ms-access/obespechenie-celostnosti-dannykh.html (дата обращения: 15.10.2025).
88. Пользовательский интерфейс к базе данных Oracle. Архитектура ИТ-решений. URL: https://it-architecture.ru/oracle/oracle-database-user-interface.html (дата обращения: 15.10.2025).
89. Интерфейс базы данных / Простое создание форм. Reddit. URL: https://www.reddit.com/r/selfhosted/comments/ou542p/%D0%B8%D0%BD%D1%82%D0%B5%D1%80%D1%84%D0%B5%D0%B9%D1%81_%D0%B1%D0%B0%D0%B7%D1%8B_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85_%D0%BF%D1%80%D0%BE%D1%81%D1%82%D0%BE%D0%B5_%D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%BD%D0%B8%D0%B5_%D1%84%D0%BE%D1%80%D0%BC/ (дата обращения: 15.10.2025).
90. Руководство по пользовательскому интерфейсу Access. Microsoft Support. URL: https://support.microsoft.com/ru-ru/office/%D1%80%D1%83%D0%BA%D0%BE%D0%B2%D0%BE%D0%B4%D1%81%D1%82%D0%B2%D0%BE-%D0%BF%D0%BE-%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D1%82%D0%B5%D0%BB%D1%8C%D1%81%D0%BA%D0%BE%D0%BC%D1%83-%D0%B8%D0%BD%D1%82%D0%B5%D1%80%D1%84%D0%B5%D0%B9%D1%81%D1%83-access-81534065-27a3-41a4-ae04-9ae92900f6b3 (дата обращения: 15.10.2025).
91. SQL — использование процедур для SELECT/UPDATE/INSERT/DELETE. Habr. URL: https://habr.com/ru/companies/mailru/articles/592385/ (дата обращения: 15.10.2025).
92. Ограничение целостности — MS Access. Киберфорум. URL: https://www.cyberforum.ru/microsoft-access/thread2949704.html (дата обращения: 15.10.2025).
93. Какие существуют способы обеспечения целостности данных в Access? Вопросы к Поиску с Алисой (Яндекс Нейро). URL: https://yandex.ru/q/question/kakie_sushchestvuiut_sposoby_obespecheniia_a0945934/ (дата обращения: 15.10.2025).