Архитектура многопользовательских СУБД

 

Существует три типовых архитектурных решения при реализации многопользовательских СУБД:

обычная телеобработка;

файловый сервер;

технология клиент/сервер.

Телеобработка (рис.8) предполагает наличие одного компьютера с единственным процессором, который соединен с несколькими терминалами.

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

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

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

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

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

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

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

большим объемом сетевого трафика;

на каждой рабочей станции должна работать полная копия СУБД;

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

Технология клиент/сервер (рис.10) была разработана с целью устранения недостатков, имеющихся в первых двух подходах. Клиент/сервер означает такой способ взаимодействия программных компонентов, при котором они образуют единую систему. Существует некий клиентский процесс, требующий определенных ресурсов, а также серверный процесс, который эти ресурсы предоставляет. При этом совсем необязательно, чтобы оба процесса находились на одном и том же компьютере. На практике принято размещать сервер на одном узле локальной сети, а клиенты – на других узлах.

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

 

Клиент, получив ответ от сервера, отображает полученные данные пользователю.

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

обеспечивает более эффективный доступ к существующим базам данных;

повышается общая производительность системы (клиенты и серверы находятся на разных компьютерах, на сервере выполняется только работа с БД).

стоимость аппаратного обеспечения снижается (достаточно мощный компьютер нужен только серверу);

сокращаются коммуникационные расходы (существенно сокращается объем пересылаемых по сети данных);

повышается уровень непротиворечивости данных (все ограничения определяются и проверяются только в одном месте – на сервере, каждому приложению не надо выполнять собственную проверку).

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

Языки баз данных

Внутренний язык СУБД для работы с данными состоит из двух частей: языка определения данных (DDL) и языка управления данными (DML). Язык DDL используется для определения схемы базы данных, а язык DML – для чтения и обновления данных, хранимых в базе. Эти языки называются подъязыками данных, поскольку в них отсутствуют конструкции для выполнения всех вычислительных операций, обычно используемых в языках программирования высокого уровня. Во многих СУБД предусмотрена возможность внедрения операторов подъязыка данных в программы, написанные на таких языках программирования высокого уровня, как Pascal или C. В этом случае язык высокого уровня принято называть базовым языком (host language). Перед компиляцией файла программы на базовом языке эти операторы подъязыка предварительно удаляются и заменяются на вызовы соответствующих функций СУБД. Затем этот предварительно обработанный файл компилируется обычным образом в объектный модуль, который затем компонуется с библиотекой, содержащей вызываемые в программе функции СУБД.

Язык определения данных – DDL, является описательным языком, который позволяет АБД или пользователю описать и поименовать сущности, необходимые для работы некоторого приложения, а также связи, имеющиеся между различными сущностями. Схема базы данных состоит из набора определений, выраженных на специальных языке определения данных – DDL. Язык DDL используется как для определения новой схемы, так и для модификации уже существующей. Этот язык нельзя использовать для управления данными. Результатом компиляции DDL-операторов является набор таблиц, хранимых в особых файлах, в которых хранятся данные, описывающие объекты базы данных – метаданные. Такой особый файл называется системным каталогом (иногда каталогом данных). Метаданные включают определения записей элементов данных, а также другие объекты, необходимые пользователям или для работы СУБД. Перед доступом к реальным данным, СУБД обычно обращается к системному каталогу.

Язык управления данными – DML, это язык, содержащий набор операторов для поддержки основных операций манипулирования данными, содержащимися в базе.

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

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

Языки DML отличаются базовыми конструкциями извлечения данных. Следует различать два типа языков DML: процедурный и непроцедурный. Основное отличие между ними заключается в том, что процедурные языки указывают то, как можно получить результат оператора языка DML, тогда как непроцедурные языки описывают то, какой результат будет получен. Как правило, в процедурных языках записи БД рассматриваются по отдельности, тогда как непроцедурные языки оперируют целыми наборами данных.

 

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

Непроцедурные языки DML – это языки, которые позволяют указать лишь то, какие данные требуются, но не то, как их следует извлекать. Непроцедурные языки позволяют определить весь набор требуемых данных с помощью одного оператора извлечения или обновления. С помощью этих языков пользователь указывает, какие данные ему нужны без определения способа их получения. СУБД транслирует выражение на языке DML в процедуру (или набор процедур), которая обеспечивает манипулирование затребованным набором записей. Данный подход освобождает пользователя от необходимости знать детали внутренней реализации структур данных и особенности алгоритмов, используемых для извлечения и возможного преобразования данных. В результате работа пользователя получает определенную степень независимости от данных. Непроцедурные языки часто также называют декларативными языками. Реляционные СУБД обычно включают поддержку непроцедурных языков DML – чаще всего это бывает язык структурированных запросов SQL или язык запросов по образцу QBE (Query-by-Example). Непроцедурные языки обычно проще понимать и использовать, чем процедурные языки DML, поскольку пользователем выполняется меньшая часть работы, а СУБД – большая.