Текст книги "Проектирование распределенных информационных систем"

6 Лекция 6. Общая характеристика распределенных баз данных

До сих пор изучались централизованные, локальные базы данных. В то же время распределенные базы данных (РБД) находят все более широкое применение в связи с массовым распространением «сетевых» технологий.

Теория создания, использования и функционирование РБД имеет свои особенности по сравнению с централизованными БД.

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

Новые требования, предъявляемые к базам данных.

Базы данных явились в значительной мере следствием развития автоматизированных систем управления (АСУ). Первоначально АСУ строились по централизованному принципу: данные из источников передавались в центральный вычислительный центр с суперЭВМ и там обрабатывались. В силу этого базы данных первоначально назывались банками данных.

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

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

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

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

Быстрое распространение сетей передачи данных, резкое увеличение объема внешней памяти ПК при ее удешевлении в 80-е годы XX в., развитие возможностей персональных компьютеров, которые по своим характеристикам в 90-е годы уже превосходили суперЭВМ 80-х годов, создали необходимую базу для реализации и широкого внедрения РБД.

Рисунок 6.1 – Схема компьютерного интегрированного полиграфического производства:

УЧ – управляющая часть; ОУ – объект управления

К достоинствам РБД относятся:

• соответствие структуры РБД структуре организаций;

• гибкое взаимодействие локальных БД;

• широкие возможности централизации узлов;

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

• высокие системные характеристики (малое время отклика за счет распараллеливания процессов, высокая надежность);

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

• возможность распределения файлов в соответствии с их активностью;

• независимые разработки локальных БД через стандартный интерфейс.

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

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

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

Возникла необходимость в теоретической проработке процессов в РБД.

Распределенная база данных (РБД) – система логически интегрированных и территориально распределенных БД, языковых, программных, технических и организационных средств, предназначенных для создания, ведения и обработки информации.

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

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

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

Атрибут – характеристика элемента данных в объекте.

Вызов процедуры – передача управления подпрограмме или процедуре с последующим возвратом к основной программе по окончании выполнения подпрограммы или процедуры.

Вызов удаленной процедуры (Remote Procedure Call) – вызов процедуры с другого компьютера.

Инкапсуляция – объединение данных и программы (кода) в «капсуле», модуле.

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

Компонент – аналог класса в приложении Delphi.

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

Локализация (размещение) – распределение данных по узлам (участкам) сети с учетом дублирования (наличия копий).

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

Метод – набор подпрограмм, оперирующих с данными.

Мост – устройство для соединения двух полностью идентичных подсетей в общую сеть.

Наследование – передача определенных свойств от класса к его производному.

Объект – комбинация элементов данных, характеризующихся атрибутами, и методов их обработки, упакованных вместе в одном модуле.

Полиморфизм – возможность переопределения процедуры в производном классе.

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

Свойство – аналог атрибута в приложении Delphi.

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

Событие – сигнал запуска метода.

Среда (Computer Aided Software Engineering – CASE) – среда создания программного обеспечения, ориентированная на разработку программы от планирования и моделирования до кодирования и документирования.

Фрагмент логический – блок данных, однородных для транзакций с точки зрения доступа.

Фрагментация (расчленение) – процесс разбиения целостного объекта глобального типа на несколько частей (фрагментов).

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

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

Дополнительными специфическими требованиями являются:

• ЯОД в рамках схемы должен быть один для всех локальных БД;

• доступ должен быть коллективным к любой области РБД с соответствующей защитой информации;

• подсхемы должны быть определены в месте сосредоточения алгоритмов (приложений, процессов) пользователя;

• степень централизации должна быть разумной;

• необходим сбор и обработка информации об эффективности функционирования РБД.

В дальнейшем Кристофер Дейт сформулировал 12 правил для РБД.

1 Локальная автономность.

2 Отсутствие опоры на центральный узел.

3 Непрерывное функционирование (развитие) РБД.

4 Независимость РБД от расположения локальных БД.

5 Независимость от фрагментации данных.

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

7 Обработка распределенных запросов.

8 Обработка распределенных транзакций.

9 Независимость от типа оборудования.

10 Независимость от операционной системы.

11 Независимость от сетевой архитектуры.

12 Независимость от типа СУБД.

В дальнейшем рассмотрении РБД выделим:

• общие вопросы (состав, работа РБД);

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

Состав и работа РБД.

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

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

Рисунок 6.2 – Схема РБД

Рисунок 6.3 – Уровни представления данных в РБД

Таблица 6.1 – Данные в РБД (глобальный уровень) «Служащий»

В таблице 6.1 разными шрифтами выделены фрагменты БД.

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

Таблица 6.2 – Пользовательский уровень в РБД

Пользовательский уровень состоит из фрагментов (например, строки 1, 2, 3 таблица «Завод» таблица 6.1) глобального уровня, которые составляют фрагментарный, логический уровень.

Выделяют горизонтальную и вертикальную фрагментации (расчленение). Горизонтальная фрагментация связана с делением данных по узлам. Горизонтальные фрагменты не перекрываются. Вертикальная фрагментация связана с группированием данных по задачам.

Фрагментация чаще всего не предполагает дублирования информации в узлах. В то же время при размещении фрагментов по узлам {локализации) распределенного уровня в узлах разрешается иметь копии той или иной части РБД. Так, например, локализация для примера в таблице 6.1 может иметь вид, показанный в таблице 6.3.

Таблица 6.3 Локализация данных

Очевидно, что для таблицы «Завод» осуществляется дублирование, а для таблицы «Сырье» – расчленение.

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

Иначе говоря, РБД можно представить в виде, показанном на рисунке 6.3.

Сеть в РБД образуют сетевые операционные системы (например, Windows NT, Novell NetWare). В качестве СУБД, изначально предназначавшихся для использования в сети, следует назвать BTrieve, Oracle, InterBase, Sybase, Informix.

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

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

Естественно, что для работы в РБД необходимы администраторы РБД и локальных БД, рабочими инструментами которых являются перечисленные словари.

Схема работы РБД показана на рисунке 6.4.

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

Рисунок 6.4 – Схема работы РБД

Если запрос связан с локальными данными, СУБД осуществляет вызов данных из локальной БД, которые поступают пользователю. Если часть данных для выполнения приложения находится в другой локальной БД, локальная СУБД дополнительно через локальные и сетевую операционные системы осуществляет удаленный вызов процедуры (Remote Procedure Call – PRC), после выполнения которой данные передаются пользователю.

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

Простейший алгоритм выбора стратегии приведен на рисунке 6.5.

Рисунок 6.5 – Алгоритм выбора стратегии хранения (А – запрос локален)

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

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

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

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

Рисунок 6.6 – Архитектура клиент – сервер

Работа в архитектуре клиент – сервер может поддерживаться и с помощью схемы Open DataBase Connectivity (ODBC), как показано на рисунке 6.7. В этом случае сеть образуется путем соединения серверов. Такое соединение обеспечивается или средствами СУБД (SQL Server) или мониторами транзакций (TUXEDO). Обсудим более подробно вариант реализации РБД – архитектуру клиент – сервер.

Рисунок 6.7 – ODBC в архитектуре клиент – сервер

Система клиент – сервер.

Совместно с термином «клиент – сервер» используются три понятия.

1 Архитектура: речь идет о концепции построения варианта РБД.

2 Технология: говорят о последовательности действий в РБД.

3 Система: рассматриваются совокупность элементов и их взаимодействие.

Об архитектуре клиент – сервер говорилось ранее. Технология клиент – сервер позволяет повысить производительность труда:

• сокращается общее время выполнения запросов за счет мощного сервера;

• уменьшается доля и увеличивается эффективность использования клиентом (для вычислений) центрального процессора;

• уменьшается объем использования клиентом памяти «своего» компьютера;

• сокращается сетевой трафик.

К таким крупномасштабным системам предъявляются следующие требования:

1) гибкость структуры;

2) надежность;

3) доступность данных;

4) легкость обслуживания системы;

5) масштабируемость приложений;

6) переносимость приложений (на разные платформы);

7) многозадачность (возможность выполнения многих приложений).

Отметим, что архитектуре клиент – сервер предшествовала архитектура файл – сервер, в которой возможны следующие варианты.

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

2. В СУБД Access, которая изначально создана как локальная, предусмотрен режим деления базы данных. Таблицы остаются на сервере (back-end), а остальные объекты (запросы, отчеты) передаются клиентам (front-end). В этом случае попрежнему большой трафик, в силу чего при использовании файл-серверов количество подключаемых клиентов – при их надежной работе – до четырех.

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

Для этого пришлось построить СУБД, изначально предназначенные для работы в сети. Фирма Microsoft вынуждена была – в дополнение к СУБД Access, которая использовалась с помощью приложения ODBC только для клиентских целей – предложить в качестве сервера Microsoft SQL Server. Такая структура оказалась тяжеловесной и неудобной, так как разработчику требовалось знать уже две СУБД.

Из других предложений очень удачным оказался программный продукт Delphi, в рамках которого могут использоваться СУБД dBase, Paradox, и, при отдельной инсталляции, InterBase (режим клиент – сервер). При этом СУБД InterBase поддерживается, наряду с языком программирования SQL, мощным, понятным, простым и широко распространенным языком программирования (Object) Pascal, построенным с применением объектно-ориентированного подхода.

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

В системе клиент – сервер возможно выделить следующие составляющие: сервер, клиент, интерфейс между клиентом и сервером, администратор.

Сервер осуществляет управление общим для множества клиентов ресурсом. Он выполняет следующие задачи:

• управляет общей БД;

• осуществляет доступ и защиту данных, их восстановление;

• обеспечивает целостность данных.

К БД на сервере предъявляются те же требования, как и к централизованной многопользовательской БД.

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

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

• предоставляет интерфейс пользователю;

• управляет логикой работы приложений;

• проверяет допустимость данных;

• осуществляет запрос и получение данных с сервера.

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

В качестве СОС могут использоваться Windows NT, Novell NetWare. Коммуникационное программное обеспечение позволяет компьютерам взаимодействовать на языке специальных программ – коммуникационных протоколов.

В общем случае такое взаимодействие осуществляется с помощью семиуровневой схемы ISO с соответствующими протоколами. Для локальных сетей схема упрощается. Протоколоми для Windows NT служит Transmission Control Program/Internet Program (TCP/IP), для NetWare – Sequenced Packed eXchange/Internet Packed eXchaned (SPX/IPX).

Разнообразие сетевых средств делает необходимым создание стандартного промежуточного программного обеспечения клиент – сервер, находящегося на сервере и клиентах. Говорят о прикладном программном интерфейсе (Application Programming Interface – API). Сюда относятся Open DataBase Connectivity (ODBC) и Integrated Database Application Programming Interface (IDAPI), используемый в приложении Delphi и СУБД InterBase.

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

При обращении пользователя к приложению компьютер-клиент запрашивает у пользователя имя и пароль. После этого – при правильном ответе – приложение может быть запущено клиентом. Приложение дает возможность подключиться к серверу, которому сообщается имя и пароль пользователя.

Если подключение осуществлено, начинает работать сервер, выполняющий два вида процессов: переднего раздела и фоновые.

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

Работа сервера может иметь такой порядок.

1 После поступления запроса диспетчер ставит его в очередь по схеме «первым пришел – первым обслужен».

2 Процесс переднего раздела выбирает «самый старый» запрос и начинает его обработку. После завершения результаты помещаются в очередь для передачи клиенту.

3 Диспетчер посылает результаты из очереди соответствующему клиенту.

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

• запись данных из БД в промежуточную (буферную) память рабочей области (при чтении) и обратно (при обновлении);

• запись в журнал транзакций;

• архивация (копирование) групп транзакций;

• аварийное завершение транзакций;

• периодическая запись на диск контрольных точек для обеспечения восстановления данных в РБД после аппаратного сбоя.

Администратор РБД (АРБД) должен решать следующие задачи.

1 Планирование РБД и распределение памяти.

2 Настройка конфигурации сети.

3 Создание РБД.

4 Работа с разработчиками приложений.

5 Создание новых пользователей и управление полномочиями.

6 Регулярная архивация БД и выполнение операций по ее восстановлению.

7 Управление доступом к БД с помощью ОС и СОС, средств защиты и доступа.

В больших системах АРБД может состоять из ряда лиц, отвечающих, например, за ОС, сеть, архивацию, защиту.

Таким образом, система клиент – сервер своеобразна: с одной стороны, ее можно считать разновидностью централизованной многопользовательской БД, с другой стороны, она является частным случаем РБД.

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

Основное ограничение для работы такой системы – минимальный трафик. Поэтому при разработке приложения, помимо обычных задач (уяснения цели приложения, логики обработки, вида интерфейса) особое внимание следует обратить на разработку DLL-сценария и распределение функций между клиентами и сервером.

Использование для составления сценария CASE-средств значительно сокращает трудоемкость работ по проектированию. Иначе эта процедура выполняется вручную с помощью команд языка SQL.

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

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

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

2 Целесообразно использовать на сервере хранимые процедуры, совокупность которых можно инкапсулировать в виде пакета (модуля). В результате трафик уменьшится: клиент будет передавать только вызов процедуры и ее параметры, а сервер – результаты выполнения процедуры.

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

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

Рисунок 6.8 – Одноуровневая – «толстый» клиент (а) и многоуровневая – «тонкий» клиент (б) структуры клиент – сервер

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

Специфические этапы создания РБД – это фрагментация и локализация.

Проектные решения на этих этапах неоднозначны, и в ряде случаев (при выборе структуры РБД) полезно использовать математическое моделирование.

РБД состоит из связанных локальных баз данных (ЛБД).

Возможны два варианта создания РБД: проектирование РБД «с нуля»; объединение (интеграция) уже готовых ЛБД.

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

Обеспечение целостности.

Будем придерживаться порядка изложения в соответствии с этапами проектирования. В качестве принципов проектирования можно использовать:

• максимум локализации данных и сокращение количества пересылаемых по кратчайшему пути данных: рекомендуется иметь до 90 % ее в локальной БД (ЛБД) узла и около 10 % – в ЛБД других узлов;

• локальность расположения данных следует определять по от ношению к наибольшему числу приложений.

В качестве критериев проектирования РБД могут быть:

1) минимум объема пересылаемых данных и сообщений;

2) минимум стоимости трафика;

3) минимум общего времени, необходимого для обслуживания запросов к БД.

В рассмотрении РБД возможно выделить два случая работы: с одним приложением и с системой приложений. Возможно нисходящее и восходящее проектирование.

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

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

• ошибки в создании структуры локальных БД и их заполнении;

• просчеты в построении структуры РБД (процедуры фрагментации и локализации);

• системные ошибки в программном обеспечении взаимодействия локальных БД (одновременный доступ);

• аварийная ситуация (неисправность технических средств) и восстановление РБД.

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

Рисунок 6.9 – проектирование РБД

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

Фрагментация и локализация.

Общая этапность проектирования РБД напоминает этапность при создании централизованной БД и отличие имеет место лишь в этапах фрагментации (расчленения) и локализации (размещения).

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

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

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

1 Полнота – все данные глобального отношения R должны быть отображены в его фрагменты.

2 Восстанавливаемость – всегда возможно восстановить глобальное отношение из фрагментов.

3 Непересечение – целесообразно, чтобы фрагменты не пересекались (дублирование производится на этапе локализации).

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

Вертикальная фрагментация с помощью проекции делит глобальное отношение (схему R) по приложениям (или по географическому признаку).

Рисунок 6.10 – Схема фрагментации и локализации данных

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

Фрагментация совместно с локализацией (рисунок 6.10) определяет в конечном итоге быстроту реакции РБД на запрос.

Обозначим узлы через j(j = l, J), а приложения – через к (к = 1, К). Если имеется отношение г со схемой R, то в узле j имеется отношение-фрагмент R^j. Если в узле j имеется к тому же копия фрагмента Ri, i(i = 1,I), то обозначим ее через Ri ^j .

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

Возможна смешанная фрагментация, которой соответствует совокупность операций селекции и проекции.

где F = {а_ij., … a_mj.};

m – число записей в горизонтальном фрагменте.

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

Воспользуемся обозначениями, введенными в данной главе.

Пусть f_kj – частота активизации приложения к в узле j; г_к. – число ссылок поиска приложения к во фрагменте i; u_k. – число ссылок обновления данных приложения к во фрагменте i; п_к. = г_к. + и_к..

Задача размещения имеет две основные разновидности: без использования и с использованием копий.