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

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

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

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

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

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

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

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

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

       Службы  поддержки независимости  от данных. СУБД должна обладать инструментами поддержки независимости программ от структуры базы данных.

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

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

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

3. Архитектура СУБД

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

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

       В настоящее время в связи с  развитием информационно-вычислительных сетей получили широкое распространение  файл-серверные и клиент-серверные  СУБД.

1. Топология архитектуры телеобработки

       Файл - серверные системы. Системы данного типа функционируют в рамках локальных вычислительных сетей (ЛВС), управляемых ОС соответствующего типа. При этом файловый сервер содержит файлы, необходимые для работы приложений и самой СУБД. Однако пользовательские приложения и сама СУБД размещены и функционируют на отдельных рабочих станциях, и обращаются к файловому серверу только по мере необходимости получения доступа к нужным им файлами - как показано на рис. 2. Таким образом, файловый сервер функционирует просто как совместно используемый жесткий диск.

2. Архитектура с использованием файлового сервера

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

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

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

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

3. Общая схема  построения систем с архитектурой "клиент/сервер"

       Клиент:

• Управляет пользовательским интерфейсом;
• Принимает и проверяет синтаксис введенного пользователем запроса;
• Выполняет приложение;
• Генерирует запрос к базе данных и передает его серверу;
• Отображает полученные данные пользователю.

       Сервер:

• Принимает и обрабатывает запросы к базе данных со стороны клиентов;
• Проверяет полномочия пользователей;
• Гарантирует соблюдение ограничений целостности;
• Выполняет запросы/обновления и возвращает результаты клиенту;
• Поддерживает системный каталог;
• Обеспечивает параллельный доступ к базе данных;
• Обеспечивает управление восстановлением.

       Этот  тип архитектуры обладает приведенными ниже преимуществами.

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

       Необходимо  заметить, что в настоящее время  данная архитектура рассматривается обычно в трехуровневом варианте, при котором функциональная часть прежнего, толстого (интеллектуального) клиента разделяется на две части. В трехуровневой архитектуре тонкий (неинтеллектуальный) клиент на рабочей станции управляет только пользовательским интерфейсом, тогда как средний уровень обработки данных управляет всей остальной логикой приложения. Третьим уровнем здесь является сepвep базы данных. Эта трехуровневая архитектура оказалась более подходящей для некоторых сред - например, для сетей Internet и intranet, где в качестве клиента может использоваться обычный Web-броузер.