Развитие БД и СУБД

Введение

 

 

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

 

Распределенные базы данных 

 

 

По общему мнению, Россия и другие страны СНГ, обладая большой территорией, просто обречены на создание и развитие информационных систем на основе распределенных баз данных. Не секрет, что практически все преуспевающие средние и крупные региональные компании имеют свои представительства в Москве и/или Петербурге. Поэтому при управлении такими предприятиями не обойтись без сложных корпоративных распределенных информационных систем. Ярким примером распределенной базы данных является система DNS:

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

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

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

Первые иерархические и сетевые  СУБД были созданы в начале 60-х  годов прошлого века. Причиной послужила  необходимость управления огромным количеством записей, связанных друг с другом, как правило, иерархическим образом (обслуживание выборов, переписей населения, моделирование ядерных испытаний, погодных и геологических явлений, информационное обеспечение космических полетов и т. д.). Причиной выбора иерархической модели во многом послужило ее подобие уже имевшимся и хорошо отработанным и освоенным на практике многочисленным массивам информации на неэлектронных носителях (банки данных, картотеки, досье, справочники). Среди реализованных на практике СУБД этого типа следует отметить системы IMS (Information Management System) компании IBM, а также TDMS (Time-Shared Date Management System) компании Development Corporation; Mark IV Multi — Access Retrieval System компании Control Data Corporation; System — 2000 разработки SAS-Institute. 

Отношения в иерархической модели данных организованы в виде совокупностей  деревьев, где дерево — структура  данных, в которой тип сегмента потомка связан только с одним  типом сегмента предка (рис. 1.1).

 
 

Рис. 1.1. Иерархическая модель БД

 

В терминологии баз данных, это  адекватно наличию жестких связей «один - к – одному» или «один - ко – многим» между записями. К недостаткам и ограничениям иерархической модели данных можно  отнести: отсутствие явного разделения логических и физических характеристик модели, что выражается в жесткой привязке БД к носителю-информации, потребность в дополнительных затратах и ухищрениях для описания неиерархических связей, что обуславливает низкую гибкость модели, не позволяющую ей эволюционировать в изменяющихся условиях. 

Сетевая модель данных — это представление  сетевыми структурами типа запись данных, связанных отношениями «один - к  – одному» или «один - ко –  многим» (рис. 1.2). Основная идеология  и стандартные требования к этой модели были разработаны комитетом Database Task Group (DTBG) на рубеже 60—70-х годов. Впервые сетевая архитектура была реализована в СУБД Integrated Data Store (IDS) компании General Electric и IDMS компании Computer Associates.

 

Рис. 1.2. Сетевая модель БД

 

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

Сетевая модель допускает также  использование в базах данных связей «многие - ко – многим». Это  позволяет устранить многие недостатки иерархической модели, такие как: низкую приспособленность к описанию данных неиерархической структуры и слабую гибкость при развитии системы. 

Реляционная модель была описана в 1970—1971 годах в работах Е. Ф. Кодда. Она основана на процедурном языке  обработки таблиц данных и языке запросов. В сетевой и иерархической моделях использовались жесткие физические подходы к связыванию записей из разных файлов путем применения физических указателей или адреса на диске. Такие базы существенно затрудняют и ограничивают операции над данными. Кроме того, является очевидным, что иерархические и сетевые базы данных весьма чувствительны к аппаратным изменениям. Перенос данных с одного накопителя на другой, или вообще Изменение числа приводит к необходимости внимательно и кропотливо изменять адреса в связях записей на новые. Также такие модели чувствительны к реструктуризации самой базы (добавление или удаление новых полей приводит к изменению физических адресов записей). Все эти проблемы преодолела реляционная модель, основанная на логических отношениях данных. Именно реляционная модель породила все современные известные СУБД, ее детищем является SQL, благодаря использованию реляционной модели возможно создание распределенных баз данных. 

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

Согласно принципам, изложенным в  трудах известного ученого Дейта, можно  выделить:

 

12 основных требований к распределенной базе данных (они же являются основными признаками)

 

 

 * локальная автономия (local autonomy); 

* децентрализация (no reliance on central site); 

* непрерывность операций (continuous operation); 

* прозрачность расположения (location independence);  

* независимая фрагментация (fragmentation independence);  

* независимое тиражирование (replication independence);  

* обработка распределенных запросов (distributed query processing); 

* обработка распределенных транзакций (distributed transaction processing); 

* независимость от оборудования (hardware independence); 

* независимость от операционных  систем (operationg system independence); 

* прозрачность сети (network independence); 

* независимость от СУБД (database independence).

Рассмотрим каждое из этих требований подробнее.

 

 

Локальная автономия

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

Децентрализация

 

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

В распределенных БД поддержка целостности  и согласованности данных, в свете  предыдущих требований, представляет собой довольно сложную проблему. Синхронное и согласованное изменение данных в нескольких локальных БД, составляющих распределенную базу данных, достигается, как правило, применением протокола двухфазной фиксации транзакций. Кроме согласования и верификации данных, этот протокол может выполнять защиту от сбоев в системе в критических случаях (обрыв связи, например). Если распределенная БД однородна — т. Е. на всех узлах данные хранятся в формате одной базы и на всех узлах функционирует одна и та же СУБД, то используется механизм двухфазной фиксации транзакций для конкретной СУБД. В случае же неоднородности распределенной БД, для обеспечения согласованных изменений в нескольких базах данных, используют менеджеры распределенных транзакций. Это, однако, возможно, если участники обработки распределенной транзакции (СУБД, функционирующие на узлах системы), поддерживают ХА-интерфейс, определенный в спецификации DTP консорциума Х/Ореn. ХА-интерфейс имеют, например, Informix, Microsoft SQL Server, Oracle, Sybase, CA-Openlngres. 

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

Непрерывность операций

 

 Это качество можно  трактовать как возможность непрерывного доступа (формат 24x7 — доступ 24 часа в сутки 7 дней в неделю) в рамках распределенной БД к данным вне зависимости от их расположения и операций, выполняемых на локальных узлах. Одним словом, данные доступны всегда, а операции над ними могут выполняться непрерывно. 

Прозрачность расположения

 

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

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

Независимая фрагментация

 

 Это свойство трактуется как возможность распределенного (т. Е. на различных узлах, а не в  одном месте) размещения данных, логически  представляющих собой единое целое. Существует фрагментация двух типов: горизонтальная и вертикальная. Первая означает хранение строк одной таблицы на различных узлах (фактически, хранение строк одной логической таблицы в нескольких идентичных физических таблицах на различных узлах). Вторая означает распределение столбцов логической таблицы по нескольким узлам (типичный пример реализации — SQL-запрос из нескольких физически обособленных таблиц).

Независимое тиражирование

 

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

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

Тиражирование данных — это асинхронный перенос изменений объектов исходной базы данных в базы, принадлежащие различным узлам распределенной системы. Функции тиражирования выполняет, как правило, специальный модуль СУБД — сервер тиражирования данных, называемый репликатором (СУБД CA-Openlngres и Sybase). В других СУБД (Informix-OnLine Dynamic Server) регашкатор встроен в сервер или поставляется опционально (Oracle). Специфика механизмов репликации данных зависит от используемой СУБД. Один из простейших вариантов репликации — использование так называемых «моментальных снимков» (Snapshot) — сохранение на разных узлах копий той или иной таблицы в определенный момент времени; данные копии периодически (раз в неделю, например) подлежат обновлению.  

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