Архитектура распределенных СУБД

                                                СОДЕРЖАНИЕ 

Введение…………………………………………………………………………...3

1. Понятие  распределенных и параллельных  СУБД……………………………4

2. Функциональные  возможности СУБД………………………………………..6

3.Архитектура  распределенных СУБД…………………………………………..7

Заключение……………………………………………………………………….10

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

     . 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

                                                      ВВЕДЕНИЕ 

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

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

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

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

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

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

     1. Понятие распределенных  и параллельных  СУБД

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

     Существует множество  альтернатив распределенной обработки.

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

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

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

     Архитектуры параллельных систем варьируются между двумя крайними точками, называемыми архитектура без разделяемых ресурсов (shared-nothing) и архитектура с разделяемой памятью (shared-memory). Промежуточную позицию занимает архитектура с разделяемыми дисками (shared-disk).

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

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

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

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

     Примерами систем параллельных баз данных являются продукты DBC (Teradata) и NonStop-SQL (Tandem), а также  ряд прототипов, таких как BUBBA, EDS, GAMMA, GRACE, PRISMA и ARBRE.

     Подход c разделяемой памятью заключается  в том, что каждый процессор посредством  быстрых линий связи (высокоскоростных шин или координатных коммутаторов) соединен со всеми модулями памяти и дисковыми устройствами. Существуют несколько типов мэйнфреймов, следующих этому подходу: IBM3090, DPS8 (Bull), а также симметричные многопроцессорные системы типа Sequent и Encore. Две сильные стороны систем с разделяемой памятью – простота и хорошая балансировка нагрузки. Три наиболее существенные проблемы, связанные с этим подходом, – стоимость, ограниченная масштабируемость, невысокая надежность.

     К системам параллельных баз данных с  разделяемой памятью относятся XPRS, DBS3 и Volcano, а также перенесенные на мультипроцессоры с разделяемой памятью наиболее известные промышленные СУБД. Первым примером такой системы была реализация СУБД DB2 на IBM3090 с шестью процессорами. Во всех известных на сегодня коммерческих продуктах (таких как Ingres и Oracle) используется только межзапросный (но не внутризапросный) параллелизм.

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

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

     Примеры параллельных СУБД с разделяемыми дисками: продукт IMS/VS Data Sharing (IBM), а также продукты VAX DBMS и Rdb компании DEC. Реализация Oracle на компьютерах VAXcluster (DEC) и NCUBE также использует разделение дисков, поскольку этот подход требует минимальных расширений в ядре СУБД. Отметим, что во всех этих системах применяется только межзапросный параллелизм. 

     2. Функциональные возможности  СУБД

     Управляющим компонентом многих СУБД является ядро, выполняющее следующие функции:

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

     Непосредственное  управление данными  во внешней памяти.

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

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

     Управление  буторами оперативной  памяти.

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

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

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

     Управление  транзакциями.

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

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

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

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

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

     3.Архитектура  распределенных СУБД

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

     Коммуникационной  сети присущи следующие свойства:

     1.  каждый узел-это полноценная СУБД сама по себе;

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

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

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

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

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

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

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

     Трехуровневая архитектура ANSI-SPARС для СУБД представляет собой типовое решение для централизованных СУБД.

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

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

• набор глобальных внешних схем
• глобальную концептуальную схему
• схему фрагментации и схему распределения
• набор схем для каждой локальной СУБД, отвечающих требованиям трёхуровневой архитектуры ANSI-SPARС.

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

     Глобальная концептуальная схема.

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

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

     Схемы фрагментации и распределения.

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

     Локальные схемы.

     Каждая  локальная СУБД имеет свой собственный  набор схем.

     Локальная концептуальная и локальная внутренняя схемы полностью соответствуют эквивалентным уровням архитектуры ANSI-SPARС.

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

                                               ЗАКЛЮЧЕНИЕ 

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

     Для этого использовались различные  картотеки, папки, журналы, библиотечные каталоги.

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

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

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

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

                 СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ 

1. Голицина  О.Л., Максимов Н.В., Попов И.И. Базы данных: Учебное пособие. – М.: ФОРУМ: ИНФРА-М, 2009. – 352 с.
2. Карпова Т.С. Базы данных: модели, разработка, реализация. – СПб.: Питер, 2010. – 304 с.
3. Смородинский А. В., Ривкин М. Н. Базы данных: тенденции развития // Мир ПК, 1990, N 3.
4. Смородинский А. В., Ривкин М. Н. Системы управления базами данных и оболочки экспертных систем для персональных компьютеров. - Тверь, 1991.