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

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

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

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

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

Реляционная модель данных: принципы и правила Кодда

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

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

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

• Правило 0 (Foundation Rule): «Система, позиционируемая как реляционная СУБД, должна управлять базами данных исключительно с использованием своих реляционных возможностей». Это означает, что для работы с данными не должно требоваться никаких других средств, кроме реляционных операций.
• Правило 1 (The Information Rule): «Вся информация в реляционной базе данных должна быть представлена исключительно на логическом уровне и только одним способом — в виде значений, содержащихся в таблицах». Это фундаментальное правило подчеркивает единообразие представления данных.
• Правило 2 (Guaranteed Access Rule): «Логический доступ к каждому элементу данных должен обеспечиваться путем использования комбинации имени таблицы, значения первичного ключа и имени столбца». Это гарантирует уникальный и однозначный доступ к любому элементу данных.
• Правило 3 (Systematic Treatment of NULL Values): «Система должна требовать полной поддержки значений NULL, отличающихся от строки символов нулевой длины, строки пробельных символов, а также от нуля или любого другого числа, для представления отсутствующей и неприменимой информации». Правильное обращение с NULL-значениями критически важно для корректной обработки неполных или неизвестных данных.

Остальные правила Кодда, такие как «Правило 4 (Active On-Line Catalog Based on the Relational Model)», требующее, чтобы метаданные хранились в реляционных таблицах и были доступны через стандартный язык, или «Правило 11 (Distribution Independence)», гласящее, что распределение данных по сети не должно влиять на программы-приложения, лишь подчеркивают целостность и дальновидность его концепции. Эти правила обеспечивают высокую степень независимости данных от приложений, что является важнейшим аспектом для долгосрочной эксплуатации и развития информационных систем.

Концепции распределенных баз данных

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

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

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

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

Свойства транзакций и согласованность данных

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

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

• Атомарность (Atomicity): Это свойство гарантирует, что транзакция выполняется полностью или не выполняется вовсе. В случае любого сбоя или ошибки в процессе выполнения транзакции, все изменения, внесенные ею, отменяются (откатываются), возвращая систему в исходное состояние. Например, перевод денег с одного счета на другой состоит из двух операций: списание со счета A и зачисление на счет B. Атомарность гарантирует, что либо обе операции будут выполнены, либо ни одной, исключая ситуацию потери денег.
• Согласованность (Consistency): Это свойство означает, что транзакция переводит базу данных из одного согласованного состояния в другое, не нарушая бизнес-логику и ограничения целостности, определенные в схеме базы данных. Например, если в банке установлен лимит на сумму снятия наличных, транзакция, превышающая этот лимит, не будет выполнена. Согласованность данных (консистентность) в целом означает, что данные в базе всегда находятся в корректном и ожидаемом состоянии с учетом всех определенных правил и ограничений.
• Изолированность (Isolation): Это свойство обеспечивает, что результаты одной транзакции невидимы для других параллельно выполняющихся транзакций до ее полного завершения. Параллельные транзакции выглядят для пользователей как последовательные, предотвращая конфликты и обеспечивая предсказуемость.
• Долговечность (Durability): После успешного завершения транзакции (фиксации) изменения надежно сохраняются и не могут быть утеряны даже в случае системных сбоев (например, отключения электроэнергии). Это обычно достигается путем записи изменений в постоянное хранилище (журнал транзакций, диски).

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

• Согласованность (Consistency, C): Все узлы в системе видят одни и те же данные в один и тот же момент времени. Любое чтение возвращает самые последние записанные данные.
• Доступность (Availability, A): Каждый запрос к системе получает ответ в любой момент времени (успех или неудача), без гарантии того, что данные актуальны. Система всегда отвечает на запросы.
• Устойчивость к разделению сети (Partition tolerance, P): Система продолжает функционировать даже в условиях сетевых разделений, когда узлы не могут общаться друг с другом. Это означает, что система может пережить потерю части сети.

CAP-теорема вынуждает архитекторов распределенных систем делать выбор между этими свойствами. На практике большинство современных распределенных систем выбирают между обеспечением Согласованности и Устойчивости к разделению (CP-системы) или Доступности и Устойчивости к разделению (AP-системы).

Например, традиционные реляционные базы данных, такие как PostgreSQL, MySQL или MS SQL Server, в распределенной конфигурации, как правило, стремятся к модели CP. Они отдают приоритет согласованности данных, что может приводить к временной недоступности части системы в случае сетевого разделения, пока согласованность не будет восстановлена. Ярким примером CP-системы является также MongoDB в своей конфигурации по умолчанию, где чтение и запись выполняются через мастер-ноду, что обеспечивает согласованность, но может снизить доступность при отказе мастера.

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

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

Декомпозиция и распределение данных в распределенных реляционных системах

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

Методы фрагментации данных

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

1. Горизонтальная фрагментация: Этот метод подразумевает, что строки одной логической таблицы распределяются по различным узлам. Каждая строка (или группа строк) хранится на отдельном сервере, но все эти строки вместе составляют полную исходную таблицу.
   • Пример применения: Горизонтальная фрагментация широко используется в социальных сетях для распределения огромного количества пользовательских данных, сообщений, постов и медиафайлов. Например, данные о пользователях могут быть разделены по географическому признаку или по диапазону идентификаторов.
   • Стратегии горизонтальной фрагментации:
     • Шардирование на основе диапазонов (Range-based sharding): Данные делятся на основе диапазонов значений определенного ключа (например, ID пользователя, дата создания записи, географический регион). Например, в интернет-магазине товары могут быть распределены по серверам в зависимости от их ценового диапазона. Этот подход эффективен для запросов к диапазонам, но может привести к неравномерному распределению данных и возникновению «горячих точек» (узлов с высокой нагрузкой), если выбранный ключ не обеспечивает равномерного распределения.
     • Шардирование на основе хеша (Hash-based sharding): Ключ шардирования (например, ID пользователя) хешируется, и результат хеширования используется для определения, на какой шард (узел) поместить данные. Этот метод обеспечивает более равномерное распределение данных по узлам, снижая вероятность «горячих точек», но усложняет выполнение запросов к диапазонам и добавление новых шардов в систему.
2. Вертикальная фрагментация: При этом методе столбцы одной логической таблицы распределяются по нескольким узлам. Например, часть столбцов, содержащих часто запрашиваемую информацию, может храниться на одном узле, а менее часто используемые или конфиденциальные данные — на другом.
   • Пример применения: Вертикальная фрагментация может быть полезна для обеспечения конфиденциальности данных (например, чувствительные персональные данные хранятся на защищенном сервере, а общедоступная информация — на другом), а также для оптимизации производительности, когда часть столбцов используется значительно чаще других. Например, информация о профиле пользователя может быть на одном сервере, а списки его друзей или история активности — на другом.
   • Функциональное/вертикальное шардирование: Таблицы или группы таблиц, связанные с определенными функциями приложения, размещаются на отдельных серверах. Например, данные о пользователях могут храниться отдельно от данных о заказах или платежах.
3. Смешанная фрагментация: Как следует из названия, это комбинация горизонтальной и вертикальной фрагментации. Сначала таблица может быть горизонтально фрагментирована по строкам, а затем каждый из полученных горизонтальных фрагментов может быть дополнительно вертикально фрагментирован по столбцам. Этот метод позволяет достичь максимальной гибкости и оптимизации, но при этом усложняет управле��ие и администрирование системы.

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

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

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

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

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

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

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

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

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

Когда операция одной транзакции распределена по нескольким узлам, необходимо обеспечить, чтобы либо все ее части были успешно завершены, либо ни одна из них. Для решения этой задачи используются специальные протоколы управления распределенными транзакциями. Наиболее известным и широко применяемым из них является двухфазная фиксация (Two-Phase Commit, 2PC).

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

1. Фаза 1 (Подготовка, Vote Request):
   • Координатор (специальный сервер распределенной БД, отвечающий за управление транзакцией) отправляет всем участвующим локальным серверам (участникам транзакции) уведомление с запросом подготовиться к фиксации.
   • Каждый участник выполняет все операции транзакции локально, записывает их в свой журнал транзакций, но не фиксирует. Затем он сообщает координатору о своей готовности к фиксации или об отказе (например, из-за ошибки).
   • Если все участники сообщают о готовности, координатор принимает решение о фиксации. Если хотя бы один участник сообщает об отказе, или координатор не получает ответ от кого-либо из участников в течение определенного времени, координатор принимает решение об откате транзакции на всех узлах.
2. Фаза 2 (Фиксация/Откат, Commit/Rollback):
   • Если решение о фиксации: Координатор направляет команду «зафиксировать» всем узлам-участникам. Каждый участник фиксирует транзакцию локально и сообщает координатору об успешной фиксации.
   • Если решение об откате: Координатор направляет команду «откатить» всем узлам-участникам. Каждый участник откатывает транзакцию локально и сообщает координатору об успешном откате.
   • При потере связи с каким-либо участником после принятия решения, координатор продолжает попытки завершить транзакцию (фиксацию или откат) до восстановления связи.

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

• Производительность: 2PC значительно увеличивает задержки из-за необходимости многократного обмена сообщениями и согласования между координатором и всеми участниками. Это снижает общую пропускную способность системы, что критично для высоконагруженных приложений.
• Риск блокировок (Blocking): Если координатор выходит из строя после того, как участники завершили фазу подготовки, но до того, как он разослал команду фиксации или отката, участники могут оставаться в неопределенном (заблокированном) состоянии. Они будут удерживать ресурсы (блокировки) до тех пор, пока связь не восстановится, или координатор не будет заменен и сможет завершить протокол. Это может привести к «зависанию» системы.
• Единая точка отказа: Координатор в 2PC является единой точкой отказа. Его отказ может привести к зависанию распределенных транзакций и, как следствие, к несогласованности данных, если его состояние не может быть восстановлено или передано другому узлу.
• Сложность реализации: Корректная реализация 2PC, особенно с учетом обработки ошибок и восстановления после сбоев, является достаточно сложной задачей.

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

Стратегии репликации данных

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

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

По способу синхронизации данных:

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

По типу серверной архитектуры:

• Однолидерная репликация (Master-Slave / Master-Replica): В этой архитектуре существует одна первичная база данных (мастер), которая обрабатывает все операции записи. Реплики (подчиненные) получают изменения от мастера и соответствующим образом обновляют свои данные.
  • Преимущества: Простота реализации, гарантированная согласованность записей (единый источник истины), масштабирование операций чтения (запросы на чтение могут распределяться между репликами).
  • Недостатки: Мастер является единой точкой отказа для операций записи, что может привести к временной недоступности записи при его сбое.
• Многолидерная репликация (Master-Master / Bidirectional): Позволяет нескольким первичным базам данных одновременно принимать операции записи. Изменения, внесенные в одну базу данных, реплицируются в другие, обеспечивая синхронизацию.
  • Преимущества: Лучшая отказоустойчивость и балансировка нагрузки при записи, так как нет единой точки отказа.
  • Недостатки: Требует сложных механизмов разрешения конфликтов, которые могут возникнуть при одновременных изменениях одних и тех же данных на разных лидерах. Симметричная репликация, являющаяся частным случаем многолидерной, позволяет обновлять данные из любого места системы, при этом все копии могут обновляться одновременно, но все изменения одной копии должны попасть во все остальные. Обработка конфликтов здесь становится еще более критичной.
• Безлидерная репликация: В этой архитектуре любой узел в системе может выступать в роли мастера, принимая записи и обрабатывая запросы. Для обеспечения согласованности используются кворумные протоколы.
  • Преимущества: Максимальная гибкость, высокая доступность и устойчивость к сбоям, отсутствие единой точки отказа.
  • Недостатки: Сложность в обеспечении строгой согласованности данных, требует тщательного выбора параметров кворума и механизмов разрешения конфликтов.

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

Проектирование распределенной реляционной БД для правительственного учреждения: Вызовы и решения

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

Особенности и требования государственного сектора

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

• Безопасность: Это критически важный аспект. Базы данных должны быть защищены от несанкционированного доступа, внесения изменений, уничтожения или раскрытия информации. Безопасность включает в себя не только технические меры, но и организационные процедуры. Любая утечка данных в правительственном учреждении может иметь далеко идущие юридические, финансовые и репутационные последствия.
• Конфиденциальность: Требуется обеспечить доступ к данным только строго санкционированным пользователям и предотвратить разглашение или утечку критичной информации. Это особенно актуально для персональных данных граждан, государственной тайны, служебной информации ограниченного распространения.
• Надежность: Информационные системы государственных органов должны функционировать бесперебойно, 24/7. Надежность обеспечивается дублированием системных компонентов для исключения одиночных точек отказа, регулярным созданием резервных копий (бэкапов), настройкой репликации данных и балансировкой нагрузки. В случае сбоя, система должна быть способна быстро восстановиться с минимальной потерей данных.
• Целостность данных: Данные должны быть точными, полными и согласованными. Любые изменения должны быть корректно отражены во всех связанных записях, а правила бизнес-логики должны строго соблюдаться.

В Российской Федерации специфические требования к защите данных в государственном секторе регулируются рядом нормативно-правовых актов, ключевым из которых является Федеральный закон от 27 июля 2006 года № 152-ФЗ «О персональных данных». Этот закон определяет порядок обработки персональных данных государственными органами, органами местного самоуправления, юридическими и физическими лицами, а также устанавливает строгие требования к обеспечению их безопасности. В частности, он требует принятия правовых, организационных и технических мер для защиты персональных данных от неправомерного или случайного доступа, уничтожения, изменения, блокирования, копирования, предоставления, распространения, а также от иных неправомерных действий. Соблюдение 152-ФЗ является обязательным условием для всех информационных систем, работающих с персональными данными граждан РФ. Насколько серьёзно правительственные учреждения относятся к выполнению этих требований, учитывая потенциальные последствия их нарушения?

Механизмы обеспечения защищенности и надежности

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

Механизмы обеспечения защищенности данных:

• Аутентификация и авторизация: Аутентификация подтверждает подлинность пользователя (кто вы?), а авторизация определяет его права и привилегии (что вы можете делать?). В государственных системах используются многофакторная аутентификация и строгие политики паролей.
• Контроль доступа: Механизмы контроля доступа на основе ролей (Role-Based Access Control, RBAC) позволяют назначать пользователям определенные роли, каждая из которых имеет строго определенный набор разрешений на доступ к данным и функциям системы.
• Мониторинг и аудит: Постоянный мониторинг активности в базе данных и ведение подробных журналов аудита позволяют отслеживать все действия пользователей, выявлять подозрительную активность и расследовать инциденты безопасности.
• Обнаружение и предотвращение атак (IDS/IPS): Системы обнаружения и предотвращения вторжений помогают выявлять и блокировать попытки несанкционированного доступа и вредоносных действий.
• Межсетевые экраны (Firewalls): Сетевые и прикладные межсетевые экраны ограничивают сетевой доступ к базам данных, разрешая только авторизованный трафик.
• Механизм представлений (View): Представления являются мощным и гибким инструментом защиты данных. Они позволяют скрыть от определенных пользователей некоторые таблицы или столбцы, предоставляя доступ только к необходимой информации, агрегированной или отфильтрованной.
• Хранимые процедуры, функции и триггеры: Реализация правил «бизнес-логики» непосредственно в базе данных с помощью хранимых процедур, функций и триггеров обеспечивает значительно более высокий уровень защиты данных, чем их реализация в клиентских программах. Это гарантирует, что правила всегда будут соблюдаться, независимо от используемого приложения, и предотвращает возможность обхода ограничений.

Механизмы обеспечения надежности:

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

Вызовы реализации и эксплуатации

Внедрение и эксплуатация распределенных баз данных в государственном секторе сопряжены с рядом серьезных вызовов:

• Сложность обеспечения безопасности из-за разнообразия систем: Государственные учреждения часто используют множество разнородных информационных систем (автоматизированные банковские системы (АБС), CRM, ERP, системы документооборота и т.д.), каждая из которых может иметь свои особенности и уязвимости. Интеграция этих систем и обеспечение единой политики безопасности представляет собой колоссальную сложность.
• Отсутствие удобного интерфейса и централизованной настройки аудита: Многие существующие СУБД не предоставляют удобных средств для централизованной настройки правил аудита и мониторинга активности, что создает проблемы для крупных распределенных компаний с множеством баз данных.
• Невозможность контроля действий пользователей в приложениях с трехзвенной архитектурой: В системах с трехзвенной архитектурой (клиент-сервер-БД) или веб-приложениях, где запросы к базе данных формируются серверным приложением, сложно отслеживать действия конечных пользователей. СУБД видит только запросы от серверного приложения, но не знает, кто из пользователей инициировал эти запросы.

Для преодоления этих вызовов предлагаются специализированные решения в области информационной безопасности:

• Системы мониторинга активности баз данных (Database Activity Monitoring, DAM): DAM-системы позволяют проводить глубокий аудит всех запросов к базам данных, выявлять аномальную активность, классифицировать данные и обнаруживать уязвимости. Они предоставляют централизованные средства для мониторинга и отчетности, что крайне важно для государственных учреждений.
• Межсетевые экраны для баз данных (Database Firewall, DBF): DBF-системы обеспечивают проактивную защиту, фильтруя и блокируя нежелательные запросы к базам данных в реальном времени. Они могут предотвращать SQL-инъекции, несанкционированный доступ и другие атаки, действуя как барьер между приложением и базой данных.
• Системы классификации данных: Автоматическая классификация данных позволяет определить степень чувствительности информации и применить соответствующие меры защиты.
• Интегрированные платформы безопасности: Внедрение комплексных платформ, которые объединяют функциональность DAM, DBF, управления уязвимостями и контроля доступа, позволяет создать эшелонированную защиту для всех баз данных правительственного учреждения.

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

Роль MS Access в разработке распределенных реляционных баз данных

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

Обзор возможностей MS Access для реляционных БД

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

Основные функциональные возможности MS Access включают:

• Создание таблиц: Access позволяет легко проектировать таблицы, определять поля, их типы данных и свойства. Она поддерживает первичные и внешние ключи, что критически важно для обеспечения целостности данных в реляционной модели. Наличие ключевых полей гарантирует уникальность записей и позволяет устанавливать связи между таблицами.
• Запросы: С помощью Access можно создавать различные типы запросов (выборки, обновления, добавления, удаления) как в графическом конструкторе, так и с использованием стандартного языка SQL (Structured Query Language). Это позволяет эффективно извлекать, фильтровать и манипулировать данными.
• Формы: Access предоставляет мощные инструменты для разработки пользовательских форм, которые служат интерфейсом для ввода, просмотра и редактирования данных. Формы могут быть настроены с высокой степенью детализации для удобства пользователей.
• Отчеты: Возможности Access по созданию отчетов позволяют представлять данные в наглядном и структурированном виде, группировать информацию, выполнять расчеты и выводить результаты на печать или в электронные форматы.
• Макросы и модули VBA: Встроенный язык Visual Basic for Applications (VBA) позволяет расширять функциональность базы данных, автоматизировать задачи, создавать сложные алгоритмы обработки данных и разрабатывать прикладное программное обеспечение.
• Импорт и связывание данных: Access способна импортировать данные из различных источников (текстовые файлы, электронные таблицы Excel, другие базы данных), а также связывать их с данными, содержащимися в других БД или приложениях. Это делает ее удобным инструментом для интеграции данных.
• Совместимость с ODBC: Access совместима с базами данных, поддерживающими стандарт Open Database Connectivity (ODBC), что позволяет ей подключаться к серверным СУБД, таким как SQL Server, DB2, Oracle. Это открывает возможности для использования Access в качестве фронтенда для более мощных серверных баз данных.
• Эффективность для связанных таблиц: Access эффективно работает со связанными таблицами, что позволяет минимизировать общий объем базы данных за счет разбиения повторяющихся данных на несколько связанных таблиц и соблюдения принципов нормализации.

Ограничения MS Access в распределенной и многопользовательской среде

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

• Ограничение по размеру файла: Максимальный размер файла базы данных Access (.accdb или .mdb) составляет 2 ГБ. Это включает в себя все объекты базы данных (таблицы, запросы, формы, отчеты, макросы, модули) и сами данные. Для государственных учреждений, где объемы данных могут быть колоссальными (миллионы записей о гражданах, документах, транзакциях), это ограничение является непреодолимым. Хотя теоретически можно обойти это ограничение путем связывания таблиц из нескольких файлов Access, каждый из которых не превышает 2 ГБ, это значительно усложняет администрирование и снижает производительность.
• Ограничение на количество одновременных пользователей: MS Access хранит данные в собственном формате на основе ядра Access Jet и ориентирована на локальное или небольшое сетевое использование. Официально заявленное количество одновременно работающих пользователей достигает 255. Однако на практике для обеспечения стабильной и приемлемой производительности рекомендуется не более 7-10 активных пользователей при использовании Access в качестве бэкенда (хранилища данных) в сетевой среде. При значительном увеличении числа пользователей (свыше 10-20) возникают серьезные проблемы с производительностью, блокировками и стабильностью работы.
• Проблемы с совместным использованием через облачные хранилища: Использование облачных хранилищ, таких как OneDrive, SharePoint или Google Drive, для совместного доступа к файлу базы данных Access крайне не рекомендуется и может вызвать серьезные проблемы. Облачные сервисы часто создают локальные копии файла, что приводит к рассинхронизации данных, конфликтам, повреждению базы данных и потере информации. Access не предназначена для работы с файлами, которые постоянно синхронизируются или изменяются извне.
• Отсутствие полноценной архитектуры распределенной СУБД: Access работает одновременно только с одной базой данных (одним файлом). Она не обладает встроенными механизмами для горизонтальной или вертикальной фрагментации, репликации между узлами, протоколами двухфазной фиксации или кворумными протоколами. Это означает, что Access не может быть использована как полноценная распределенная СУБД для масштабных систем.
• Ограниченная масштабируемость и производительность: Для больших объемов данных и высокой нагрузки Access быстро достигает своих пределов. Производительность сильно зависит от сетевых задержек и аппаратных ресурсов рабочего места, на котором запущен Access.

Применение MS Access для моделирования и прототипирования

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

• Моделирование и прототипирование: Благодаря своему простому графическому интерфейсу и быстрому созданию таблиц, форм и запросов, Access является отличным инструментом для моделирования и прототипирования отдельных, некритичных компонентов реляционных баз данных. Например, разработчик может быстро создать прототип формы для ввода данных или отчета, чтобы продемонстрировать функциональность заказчику или протестировать бизнес-логику.
• Разработка локальных, однопользовательских систем: Для небольших отделов или персонального использования, где объемы данных невелики, а количество пользователей ограничено одним, Access может быть эффективным решением. Например, для ведения локального учета документов или небольшого справочника.
• Образовательные цели: В учебном процессе Access часто используется для изучения основ реляционных баз данных, SQL, принципов проектирования и нормализации. Она позволяет студентам получить практический опыт работы с СУБД без необходимости осваивать сложные серверные системы.
• Фронтенд для серверных СУБД: В реальных распределенных системах, особенно с большим количеством пользователей, MS Access может выступать в роли «тонкого клиента» или фронтенда, подключенного к мощной серверной СУБД (например, Microsoft SQL Server, Oracle, PostgreSQL). В этом случае Access предоставляет пользовательский интерфейс, формы и отчеты, а все данные и их обработка осуществляются на серверной СУБД. Такой подход позволяет использовать привычный и простой интерфейс Access, одновременно пользуясь масштабируемостью, надежностью и безопасностью серверных решений.

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

Заключение

В рамках данной курсовой работы была всесторонне рассмотрена сложная и многогранная тема разработки распределенной реляционной базы данных для правительственного учреждения. Мы начали с погружения в теоретические основы, где была детально изучена реляционная модель данных Эдгара Кодда, его 12 правил, ставших фундаментом для создания целостных и непротиворечивых систем. Определения реляционной и распределенной баз данных, а также СУБД, заложили основу для дальнейшего анализа. Особое внимание было уделено концепции транзакций и ACID-свойствам (Атомарность, Согласованность, Изолированность, Долговечность), без которых невозможно представить надежную систему управления данными. Критически важным аспектом стал анализ CAP-теоремы, объясняющей компромиссы между согласованностью, доступностью и устойчивостью к разделению сети в распределенных средах, с примерами CP- и AP-систем.

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

Ключевым блоком работы стало изучение специфических требований и вызовов при проектировании распределенных баз данных для государственного сектора. Была подчеркнута критическая важность безопасности, конфиденциальности и надежности информации, а также рассмотрены требования российского законодательства, в частности, Федерального закона № 152-ФЗ «О персональных данных». Мы осветили комплекс механизмов обеспечения защищенности (аутентификация, авторизация, контроль доступа, мониторинг, аудит, межсетевые экраны, представления, хранимые процедуры) и надежности (дублирование, резервное копирование, репликация, балансировка нагрузки). Были выявлены основные вызовы реализации и эксплуатации (сложность интеграции систем, контроль действий пользователей, отсутствие централизованных средств аудита) и предложены решения с использованием специализированных систем информационной безопасности, таких как DAM и DBF.

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

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

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

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

1. Базы данных Access. Общие понятия и возможности СУБД Access. URL: https://accesshelp.ru/bazy-dannyh-access/obshhie-ponyatiya-i-vozmozhnosti-subd-access/ (дата обращения: 31.10.2025).
2. Двухфазная фиксация в распределенных транзакциях // OTUS. URL: https://otus.ru/nest/1594/ (дата обращения: 31.10.2025).
3. Механизмы обеспечения защищенности данных в распределенных информационных системах // КиберЛенинка. URL: https://cyberleninka.ru/article/n/mehanizmy-obespecheniya-zaschischennosti-dannyh-v-raspredelennyh-informatsionnyh-sistemah (дата обращения: 31.10.2025).
4. Методические указания по выполнению практического задания по курсу «Распределенные базы данных и сетевые вычисления», часть 1 // Публикации ВШЭ. URL: https://publications.hse.ru/books/618296991 (дата обращения: 31.10.2025).
5. МЕТОДЫ ДЕКОМПОЗИЦИИ В РЕЛЯЦИОННЫХ БАЗАХ ДАННЫХ Костенко А.Б., Булаенк // ResearchGate. URL: https://www.researchgate.net/publication/359670607_METODY_DEKOMPOZICII_V_RELACUONNYH_BAZAH_DANNYH_Kostenko_A_B_Bulaenk (дата обращения: 31.10.2025).
6. Особенности, сферы применения и направления развития распределенных баз данных // КиберЛенинка. URL: https://cyberleninka.ru/article/n/osobennosti-sfery-primeneniya-i-napravleniya-razvitiya-raspredelennyh-baz-dannyh (дата обращения: 31.10.2025).
7. Понятия двухфазного принятия // IBM. URL: https://www.ibm.com/docs/ru/db2/11.5?topic=applications-two-phase-commit-concepts (дата обращения: 31.10.2025).
8. Примеры фрагментации данных // zabb.ru. URL: https://zabb.ru/1-primery-fragmentacii-dannyh (дата обращения: 31.10.2025).
9. Примеры использования распределенных данных—ArcMap // Документация. URL: https://desktop.arcgis.com/ru/arcmap/10.3/manage-data/geodatabases/examples-of-distributed-data-use.htm (дата обращения: 31.10.2025).
10. Принципы организации распределенных баз данных. URL: https://studfile.net/preview/17235049/page:3/ (дата обращения: 31.10.2025).
11. Принципы применения реляционных баз данных на предприятиях гражданского сектора // Современные научные исследования и инновации. URL: https://web.snauka.ru/issues/2012/10/16843 (дата обращения: 31.10.2025).
12. РАСПРЕДЕЛЕННАЯ ОБРАБОТКА ДАННЫХ // Воронежский государственный технический университет. URL: https://www.vstu.ru/upload/iblock/d76/d760d66c36746fdd7f2127163f9611f1.pdf (дата обращения: 31.10.2025).
13. Распределённая база данных // Википедия. URL: https://ru.wikipedia.org/wiki/%D0%A0%D0%B0%D1%81%D0%BF%D1%80%D0%B5%D0%B4%D0%B5%D0%BB%D1%91%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 (дата обращения: 31.10.2025).
14. Распределенные базы данных. URL: https://db-lab.ru/distributed-databases (дата обращения: 31.10.2025).
15. Распределенные и параллельные системы баз данных // Издательство «Открытые системы». URL: https://www.osp.ru/dbms/1996/02/107577/ (дата обращения: 31.10.2025).
16. Распределенные и параллельные системы баз данных. URL: https://www.intuit.ru/studies/courses/2301/579/lecture/12474?page=4 (дата обращения: 31.10.2025).
17. Распределенные транзакции // Викиконспекты. URL: https://neerc.ifmo.ru/wiki/index.php?title=%D0%A0%D0%B0%D1%81%D0%BF%D1%80%D0%B5%D0%B4%D0%B5%D0%BB%D0%B5%D0%BD%D0%BD%D1%8B%D0%B5_%D1%82%D1%80%D0%B0%D0%BD%D0%B7%D0%B0%D0%BA%D1%86%D0%B8%D0%B8 (дата обращения: 31.10.2025).
18. Распределенный SQL: альтернатива шардированию баз данных // Habr. URL: https://habr.com/ru/companies/postgrespro/articles/766792/ (дата обращения: 31.10.2025).
19. Реляционная база данных — Википедия. 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 (дата обращения: 31.10.2025).
20. Реляционная модель данных — Википедия. 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%BC%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85 (дата обращения: 31.10.2025).
21. Реляционные базы данных: основные принципы, структура и характеристики // Yandex Cloud — Документация. URL: https://cloud.yandex.ru/docs/managed-mysql/concepts/relational-database (дата обращения: 31.10.2025).
22. РЕПЛИКАЦИЯ ДАННЫХ И УПРАВЛЕНИЕ ТРАНЗАКЦИЯМИ В РАСПРЕДЕЛЕННЫХ БАЗАХ ДАННЫХ // Евразийский Союз Ученых. URL: https://www.elibrary.ru/item.asp?id=38198751 (дата обращения: 31.10.2025).
23. Система управления базами данных (СУБД): что это такое и зачем нужна // Cloud.ru. URL: https://cloud.ru/ru/docs/saas/glossary/chto-takoe-subd (дата обращения: 31.10.2025).
24. Слуцков Д. Распределение данных по сети // Google Sites. URL: https://sites.google.com/site/distribucuadatapose/ (дата обращения: 31.10.2025).
25. Согласованность данных — Википедия. URL: https://ru.wikipedia.org/wiki/%D0%A1%D0%BE%D0%B3%D0%BB%D0%B0%D1%81%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D1%81%D1%82%D1%8C_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85 (дата обращения: 31.10.2025).
26. Согласованность данных // Struchkov’s Digital Garden — struchkov.dev. URL: https://struchkov.dev/blog/data-consistency/ (дата обращения: 31.10.2025).
27. Согласованность данных: что это на самом деле такое и почему с ней все так сложно. URL: https://habr.com/ru/articles/653225/ (дата обращения: 31.10.2025).
28. Способы защиты баз данных // Группа компаний — Гарда Технологии. URL: https://gardatech.ru/company/blog/sposoby-zashchity-baz-dannykh/ (дата обращения: 31.10.2025).
29. Способы управления распределенными транзакциями в микросервисной архитектуре. URL: https://habr.com/ru/articles/583626/ (дата обращения: 31.10.2025).
30. СУБД — что это: Системы Управления Базами Данных // Skillfactory media. URL: https://skillfactory.ru/media/subd-chto-eto-sistemy-upravleniya-bazami-dannyh (дата обращения: 31.10.2025).
31. СУБД: что это, виды, структура, функции — где и как используются системы управления базами данных, примеры // Яндекс Практикум. URL: https://practicum.yandex.ru/blog/chto-takoe-subd/ (дата обращения: 31.10.2025).
32. Что такое СУБД Access? Создание БД Access // OTUS. URL: https://otus.ru/nest/post/1131/ (дата обращения: 31.10.2025).
33. Что такое СУБД? Наиболее популярные СУБД // RU-CENTER помощь. URL: https://www.nic.ru/help/chto-takoe-subd-naibolee-populyarnye-subd_10925.html (дата обращения: 31.10.2025).
34. Что такое транзакция базы данных? // AppMaster. URL: https://appmaster.io/ru/blog/chto-takoe-tranzakciya-bazy-dannykh (дата обращения: 31.10.2025).
35. Что такое транзакция / Хабр — Habr. URL: https://habr.com/ru/companies/ruvds/articles/504992/ (дата обращения: 31.10.2025).
36. Что такое транзакция и какие свойства транзакции (ACID)? // SQL Academy. URL: https://sql-academy.org/ru/lessons/18-transactions (дата обращения: 31.10.2025).
37. Что такое фрагментация? Какие виды фрагментации бывают? Какие виды фрагментации проявляются в 3 основных схемах размещения файлов?. URL: https://studfile.net/preview/17235049/page:2/ (дата обращения: 31.10.2025).
38. Что такое реляционная база данных — Академия Selectel. URL: https://selectel.ru/blog/what-is-relational-database/ (дата обращения: 31.10.2025).
39. Что такое реляционная база данных? – Amazon Web Services (AWS). URL: https://aws.amazon.com/ru/relational-database/ (дата обращения: 31.10.2025).
40. Что такое CAP-теорема и в чем заключается основная идея // GitVerse Blog. URL: https://gitverse.ru/blog/chto-takoe-cap-teorema (дата обращения: 31.10.2025).
41. Фрагментация базы данных: основные методы и случаи использования // 8host.com. URL: https://8host.com/blog/fragmentatsiya-bazy-dannykh-osnovnye-metody-i-sluchai-ispolzovaniya/ (дата обращения: 31.10.2025).