Материал: АРМ бухгалтера жилищного кооператива

Фундаментальный принцип создания распределённых баз данных («правило 0»): Для пользователя распределённая система должна выглядеть так же, как нераспределённая система.

Отсюда возникают дополнительные цели:

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

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

. Непрерывное функционирование. Распределённые системы должны предоставлять более высокую степень надёжности и доступности.

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

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

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

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

. Управление распределёнными транзакциями. Существует 2 главных аспекта управления транзакциями: управление восстановлением и управление параллельностью обработки. Что касается управления восстановлением, то чтобы обеспечить атомарность транзакции в распределённой среде, система должна гарантировать, что все множество относящихся к данной транзакции агентов (агент - процесс, который выполняется для данной транзакции на отдельном узле) или зафиксировало свои результаты, или выполнило откат. Что касается управления параллельностью, то оно в большинстве распределённых систем базируется на механизме блокирования, точно так, как и в нераспределённых системах.

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

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

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

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

Модель с централизованной архитектурой

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

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

Рис. 3.1. Централизованная архитектура

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

Модель с архитектурой "клиент-сервер"

Использование архитектуры «клиент-сервер» предполагает наличие некоторого количества компьютеров, объединенных в сеть, один из которых выполняет особые управляющие функции (является сервером сети).

Т.е. архитектура «клиент-сервер» разделяет функции приложения пользователя (называемого клиентом) и сервера. Приложение-клиент формирует запрос к серверу, на котором расположена БД, на структурном языке запросов SQL (Structured Query Languague), являющемся промышленным стандартом в мире реляционных БД. Удаленный сервер принимает запрос и переадресует его SQL-серверу БД (специальная программа, управляющая удаленной базой данных.), который обеспечивает интерпретацию запроса, его выполнение в базе данных, формирование результата выполнения запроса и выдачу его приложению-клиенту. При этом ресурсы клиентского компьютера не участвуют в физическом выполнении запроса; клиентский компьютер лишь отсылает запрос к серверной БД и получает результат, после чего интерпретирует его необходимым образом и представляет пользователю.

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

В результате работа построена следующим образом:

База данных в виде набора файлов находится на жестком диске специально выделенного компьютера (сервера сети).

СУБД располагается также на сервере сети.

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

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

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

Таким образом, СУБД возвращает результат в приложение.

Приложение, используя пользовательский интерфейс, отображает результат выполнения запросов.

Функции приложения-клиента:

− Посылка запросов серверу.

− Интерпретация результатов запросов, полученных от сервера.

−Представление результатов пользователю в некоторой форме (интерфейс пользователя).

Функции серверной части:

− Прием запросов от приложений-клиентов.

− Интерпретация запросов.

− Оптимизация и выполнение запросов к БД.

− Отправка результатов приложению-клиенту.

− Обеспечение системы безопасности и разграничение доступа.

− Управление целостностью БД.

Основные достоинства данной архитектуры по сравнению с централизованной:

Существенно уменьшает сетевой трафик.

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

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

Существенно повышает целостность и безопасность БД.

Недостатки данной архитектуры:

Внедрение архитектуры «клиент-сервер» требует существенных финансовых ресурсов.

Своевременное обновление клиентских приложений на всех компьютерах-клиентах.

4. Разновидности и особенности современных СУБД

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

.1 Характеристика реляционных СУБД

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

Реляционный подход в построении СУБД имеет ряд достоинств:

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

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

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

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

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

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

.2 Характеристика объектных СУБД

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

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

В объектной технологии свойства данных не сводятся к простым "компьютерным" типам данных. Объекты могут содержать внутри себя другие объекты или ссылки на них. Это облегчает построение точных и удобных моделей данных.

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

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

Основными понятиями, с которыми оперирует эта модель, являются следующие:

Наследование - это способность порождать один класс объектов из другого. Новый класс (подкласс) сохраняет все свойства и методы своего "родителя", кроме того, он может иметь дополнительные свойства и методы, характерные только для него. Множественное наследование подразумевает, что подкласс может иметь более одного "родителя".

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

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

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

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