База данных

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

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

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

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

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

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

Клиент:

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

Сервер:

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

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

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

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

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

3.1  Системные каталоги СУБД

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

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

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

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

• имена элементов данных из базы данных;
• типы и размеры элементов данных;
• ограничения, установленные для каждого из элементов данных.

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

Служба IRDS. Во многих системах словарь данных является внутренним компонентом СУБД, в котором хранится только информация, непосредственно связанная с этой базой данных. Однако хранимые с помощью СУБД данные обычно обеспечивают только часть всех информационных потребностей пользователей. Как правило, имеется некоторая дополнительная информация, которая хранится с помощью других инструментов - например, таких как CASE-инструменты, инструменты ведения документации, инструменты настройки и управления проектами. Каждое из упомянутых выше средств обычно имеет свой внутренний словарь данных, доступный и другим внешним инструментам. К сожалению, не существует никакого универсального способа совместного использования разных наборов информации различными группами пользователей или приложений. Результатом попытки стандартизовать интерфейс словарей данных для достижения большей доступности и упрощения их совместного использования стала разработка службы словаря информационных ресурсов (Information Resource Dictionary System - IRDS). Служба IRDS представляет собой программный инструмент, предназначенный для управления информационными ресурсами организации, а также для их документирования. Она включает определение таблиц, содержащих словарь данных, и операций, которые могут быть использованы для доступа к этим таблицам. Упомянутые операции обеспечивают непротиворечивый метод доступа к словарю данных и способ преобразования определений данных из словаря одного типа в определения другого типа. Например, с помощью службы IRDS информация, хранимая в IRDS-совместимом словаре данных СУБД DB2, может быть передана в IRDS-совместимый словарь данных СУБД Oracle или направлена некоторому приложению системы DB2.

Одним из достоинств службы IRDS является способность расширения словаря данных. Так, если пользователь захочет сохранить определения нового типа информации в каком-то инструменте (например, определения отчетов об управлении проектом - в некой СУБД), то система IRDS в данной СУБД может быть расширена для включения этой информации. Определения IRDS были приняты в качестве стандарта Международной организацией стандартизации ISO (International Organization for Standardization) (ISO, 1990; 1993).

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

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

Панельный интерфейс состоит  из набора панелей или экранов, каждый из которых предоставляет доступ к заранее описанному набору сервисов. Он несколько напоминает язык QBE и  позволяет пользователям просматривать  и изменять словарь данных. Интерфейс  командного языка состоит из набора команд или операторов, которые позволяют  выполнять манипуляции со словарем данных. Интерфейс командного языка  может вызываться интерактивно (с  терминала) или посредством внедрения  операторов в программы на языках программирования высокого уровня. Интерфейс  экспорта/импорта генерирует файл, который можно передавать между  различными IRDS-совместимыми системами. Стандарт IRDS определяет и универсальный  формат обмена информацией. Причем он не требует, чтобы база данных, лежащая  в основе словаря данных, соответствовала  какой-то одной модели данных. Именно поэтому интерфейс IRDS-сервисов способен объединять гетерогенные БД, как показано на рис. 5.

                                Рис 5 гетерогенные БД          

4. Преимущества и недостатки СУБД

СУБД обладают как преимуществами по сравнению с файловыми системами, так и недостатками, которые мы кратко рассмотрим в этом разделе.

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

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

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

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

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

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