Добавил:
Upload
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:
20. Вопросы целостности данных и распределенные Базы Данных
РБД состоит из набора узлов, связанных коммуникационной сетью, в которой:
• каждый узел — это полноценная СУБД сама по себе;
• узлы взаимодействуют между собой таким образом, что пользователь любого из них может получить доступ к любым данным в сети так, как будто они находятся на его собственном узле.
Каждый узел сам по себе является системой базы данных. Любой пользователь может выполнить операции над данными на своём локальном узле точно так же, как если бы этот узел вовсе не входил в распределённую систему. Распределённую систему баз данных можно рассматривать как партнёрство между отдельными локальными СУБД на отдельных локальных узлах.
Фундаментальный принцип создания распределённых баз данных («правило 0»): Для пользователя распределённая система должна выглядеть так же, как нераспределённая система.
Фундаментальный принцип имеет следствием определённые дополнительные правила или цели. Таких целей всего двенадцать:
1. Локальная независимость. Узлы в распределённой системе должны быть независимы, или автономны. Локальная независимость означает, что все операции на узле контролируются этим узлом.
2. Отсутствие опоры на центральный узел. Локальная независимость предполагает, что все узлы в распределённой системе должны рассматриваться как равные. Поэтому не должно быть никаких обращений к «центральному» или «главному» узлу с целью получения некоторого централизованного сервиса.
3. Непрерывное функционирование. Распределённые системы должны предоставлять более высокую степень надёжности и доступности.
4. Независимость от расположения. Пользователи не должны знать, где именно данные хранятся физически и должны поступать так, как если бы все данные хранились на их собственном локальном узле.
5. Независимость от фрагментации. Система поддерживает независимость от фрагментации, если данная переменная-отношение может быть разделена на части или фрагменты при организации её физического хранения. В этом случае данные могут храниться в том месте, где они чаще всего используются, что позволяет достичь локализации большинства операций и уменьшения сетевого трафика.
6. Независимость от репликации. Система поддерживает репликацию данных, если данная хранимая переменная-отношение — или в общем случае данный фрагмент данной хранимой переменной-отношения — может быть представлена несколькими отдельными копиями или репликами, которые хранятся на нескольких отдельных узлах.
7. Обработка распределённых запросов. Суть в том, что для запроса может потребоваться обращение к нескольким узлам. В такой системе может быть много возможных способов пересылки данных, позволяющих выполнить рассматриваемый запрос.
8. Управление распределёнными транзакциями. Существует 2 главных аспекта управления транзакциями: управление восстановлением и управление параллельностью обработки. Что касается управления восстановлением, то чтобы обеспечить атомарность транзакции в распределённой среде, система должна гарантировать, что все множество относящихся к данной транзакции агентов (агент — процесс, который выполняется для данной транзакции на отдельном узле) или зафиксировало свои результаты, или выполнило откат. Что касается управления параллельностью, то оно в большинстве распределённых систем базируется на механизме блокирования, точно так, как и в нераспределённых системах.
9. Аппаратная независимость. Желательно иметь возможность запускать одну и ту же СУБД на различных аппаратных платформах и, более того, добиться, чтобы различные машины участвовали в работе распределённой системы как равноправные партнёры.
10. Независимость от операционной системы. Возможность функционирования СУБД под различными операционными системами.
11. Независимость от сети. Возможность поддерживать много принципиально различных узлов, отличающихся оборудованием и операционными системами, а также ряд типов различных коммуникационных сетей.
12. Независимость от типа СУБД. Необходимо, чтобы экземпляры СУБД на различных узлах все вместе поддерживали один и тот же интерфейс, и совсем необязательно, чтобы это были копии одной и той же версии СУБД.
Типы распределённых баз данных
Распределённые базы данных
Мультибазы данных с глобальной схемой. Система мультибаз данных — это распределённая система, которая служит внешним интерфейсом для доступа ко множеству локальных СУБД или структурируется, как глобальный уровень над локальными СУБД.
Федеративные базы данных. В отличие от мультибаз не располагают глобальной схемой, к которой обращаются все приложения. Вместо этого поддерживается локальная схема импорта-экспорта данных. На каждом узле поддерживается частичная глобальная схема, описывающая информацию тех удалённых источников, данные с которых необходимы для функционирования.
Мультибазы с общим языком доступа — распределённые среды управления с технологией «клиент-сервер»
Классификация. Следует выделить два класса систем распределенной обработки и системы распределенных данных:
• системы распределенной обработки в основном отражают структуру и свойства многопользовательских операционных систем с базой данных, размещенной на центральном компьютере;
• системы распределенных данных обеспечивают обработку распределенных запросов, когда при обработке одного за¬проса используются информационные ресурсы, размещенные на различных ЭВМ сети. При этом, как и ранее, сле¬дует говорить как о распределенных файловых системах, так и о распределенных базах данных.
Для распределенных баз данных свойственны следующие ха¬рактеристики:
• база данных — это логически связанные, разделяемые на некоторое количество фрагментов данные;
• фрагменты распределяются по разным узлам, которые свя¬заны между собой сетевыми соединениями;
• может быть предусмотрена репликация фрагментов;
• доступ к данным на каждом узле происходит под управле¬нием СУБД, которая на каждом узле должна поддерживать работу как локальных приложений, так и глобальных.
Основные условия и требования к распределенной обработке данных:
• прозрачность относительно расположения данных (СУБД должна представлять все данные так, как если бы они были локальными);
• гетерогенность системы (СУБД должна работать с данны¬ми, которые хранятся в системах с различной архитектурой и производительностью);
• прозрачность относительно сети (СУБД должна одинаково работать в условиях разнородных сетей);
• поддержка распределенных запросов (пользователь должен иметь возможность объединять данные из любых баз, даже если они размещены в разных системах);
• поддержка распределенных изменений (пользователь дол¬жен иметь возможность изменять данные в любых базах, на доступ к которым у него есть права, даже если эти базы размещены в разных системах);
• поддержка распределенных транзакций (СУБД должна вы¬полнять транзакции, выходящие за рамки одной вычисли¬тельной системы, и поддерживать целостность распределенной БД даже при возникновении отказов как в отдель¬ных системах, так и в сети);
• безопасность (СУБД должна обеспечивать защиту всей рас¬пределенной БД от несанкционированного доступа);
• универсальность доступа (СУБД должна обеспечивать еди¬ную методику доступа ко всем данным).
Поясним некоторые из этих требований:
Прозрачность расположения. Прозрачный (для пользователя) доступ к удаленным данным предполагает использование в при¬кладных программах такого интерфейса с сервером БД, который позволяет переносить данные в сети с одного узла на другой, не требуя при этом модификации текста программы. Иными слова¬ми доступ к информационным ресурсам должен быть полно¬стью прозрачен относительно расположения данных.
Любой пользователь или любая прикладная программа опе¬рирует с одной или несколькими базами данных. В том случае, когда прикладная программа и сервер БД выполняются на од¬ном и том же узле, проблемы расположения не возникает. Для получения доступа к базе данных пользователю или программе достаточно указать имя базы, например: SQL Dbname.
Однако в том случае, когда прикладная программа запуска¬ется на локальном узле, а база данных находится на удаленном, возникает проблема идентификации удаленного узла. Для того чтобы получить доступ к базе данных на удаленном узле, необ¬ходимо указать имя удаленного узла и имя базы данных. Если использовать жестко фиксированное имя узла в паре «имя_узла, имя_БД», то прикладная программа становится за¬висимой от расположения БД. Например, обращение к БД «host:stock», где первый компонент — имя узла, будет зависимым от расположения.
Одно из возможных решений этой проблемы состоит в ис¬пользовании виртуальных имен узлов. Управление ими обеспе¬чивается специальным программным компонентом СУБД — сервером имен (Name Server), который адресует запросы клиен¬тов к серверам.
Прозрачность сети. Клиент и сервер взаимодействуют по сети с конкретной топологией; для поддержки взаимодействия всегда используется определенный протокол. Следовательно, оно должно быть организовано таким образом, чтобы обеспечивать независимость как от используемого сетевого аппаратного обеспечения, так и от протоколов сетевого обмена. Чтобы обеспечить прозрачный доступ пользователей и программ к удаленным данным в сети, объединяющей разнородные компьютеры, коммуникационный сервер должен поддерживать как можно R лее широкий диапазон сетевых протоколов (TCP/IP, DECnet SNA, SPX/IPX, NetBIOS, AppleTalk и др.).
Автоматическое преобразование форматов данных. Как толь ко несколько компьютеров различных моделей под управлением различных операционных систем соединяются в сеть, сразу воз¬никает вопрос о согласовании форматов представления данных Действительно, в сети могут быть компьютеры, отличающиеся разрядностью (16-, 32- и 64-разрядные процессоры), порядком следования байт в слове, представлением чисел с плавающей точкой и т. д. Задача коммуникационного сервера состоит в том чтобы на уровне обмена данными обеспечить согласование фор¬матов между удаленным и локальным узлами с тем, чтобы дан¬ные, извлеченные сервером из базы на удаленном узле и пере¬данные по сети, были правильно истолкованы прикладной про¬граммой на локальном узле.
Автоматическая трансляция кодов. В неоднородной компью¬терной среде при взаимодействии клиента и сервера возникает также задача трансляции кодов. Сервер может работать с одной кодовой таблицей (например, EBCDIC), клиент — с другой (на¬пример, ASCII), при этом происходит рассогласование трактов¬ки кодов символов. Поэтому, если на локальном узле использу¬ется одна кодовая таблица, а на удаленном — другая, то при пе¬редаче запросов по сети и при получении ответов на них необходимо обеспечить трансляцию кодов. Решение этой задачи также ложится на коммуникационный сервер.
Однако ни одна из существующих СУБД не дос¬тигает этого идеала вследствие следующих практических проблем:
• низкая и несбалансированная производительность сетей передачи данных, что в распределенных транзакциях силь¬но снижает общую производительность обработки;
• обеспечение целостности данных в распределенных тран¬закциях базируется на принципе «все или ничего» и требу¬ет специального протокола двухфазного завершения тран¬закций, что приводит к длительной блокировке изменяе¬мых данных;
• необходимо обеспечить совместимость данных стандартно¬го типа, для хранения которых в разных системах исполь¬зуются разные физические форматы и кодировки;
• трудности выбора схемы размещения системных каталогов. Если каталог будет храниться в одной системе, то удален¬ный доступ будет замедлен. Если будет размножен, то из¬менения придется распространять и синхронизировать;
• необходимо обеспечить совместимость СУБД разных типов и поставщиков;
• увеличение потребностей в ресурсах для координации ра¬боты приложений с целью обнаружения и устранения ту¬пиковых ситуаций в распределенных транзакциях.
Типы распределенных СУБД
В общем случае режимы работы с БД можно классифициро¬вать по следующим признакам:
• многозадачность — однопользовательский или многополь¬зовательский;
• правило обслуживания запросов — последовательное или параллельное;
• схема размещение данных — централизованная или рас¬пределенная БД.
Распределенные СУБД подразделяются на однородные и раз¬нородные.
В однородных системах все узлы используют один и тот же тип СУБД. В разнородных системах на узлах могут функциони¬ровать различные типы СУБД, использующие разные модели данных. Однородные системы значительно проще проектировать и сопровождать, добавляя новые узлы к уже существующей рас¬пределенной системе и повышая производительность системы за счет параллельной обработки информации.
Разнородные системы обычно возникают в тех случаях, когда узлы, уже эксплуатирующие свои собственные системы с базами данных, со временем интегрируются в распределенную систему. В разнородных системах для организации взаимодействия между различными типами СУБД требуется обеспечить преобразование предаваемых сообщений, для чего каждый из узлов должен иметь возможность формулировать запросы на языке той СУБД, которая используется на их локальном узле или система должна взять на себя выполнение всех необходимых преобразований.
Очевидны следующие преимущества и недостатки распределенных баз данных (табл. 7.1).
Распределенная СУБД должна иметь следующий набор функциональных возможностей:
• расширенные службы установки соединений должны обес¬печивать доступ к удаленным узлам и позволять передавать запросы и данные между узлами, входящими в сеть;
• расширенные средства ведения каталога, позволяющие со¬хранять сведения о распределении данных в сети;
• средства обработки распределенных запросов, включая ме¬ханизмы оптимизации запросов и организации удаленного доступа к данным;
• расширенные функции управления защитой, позволяющие обеспечить соблюдение правил авторизации и прав доступа к распределенным данным;
• расширенные функции управления параллельным выпол¬нением, позволяющие поддерживать целостность копируе¬мых данных;
• расширенные функции восстановления, учитывающие ве¬роятность отказов в работе отдельных узлов и отказов ли¬ний связи.
Соответственно, программные средства, обеспечивающие целевую (функциональную) обработку данных, должны быть ор¬ганизованы таким образом, чтобы обеспечить более эффектив¬ное использование совокупных вычислительных ресурсов за счет специализированного разделения функций обработки между центральным процессом СУБД и клиентскими функциональ¬но-ориентированными процедурами.
Це?лостность ба?зы да?нных (database integrity) — соответствие имеющейся в базе данных информации её внутренней логике, структуре и всем явно заданным правилам. Каждое правило, налагающее некоторое ограничение на возможное состояние базы данных, называется ограничением целостности (integrity constraint). Примеры правил: вес детали должен быть положительным; количество знаков в телефонном номере не должно превышать 25; возраст родителей не может быть меньше возраста их биологического ребёнка и т.д.
Задача аналитика и проектировщика базы данных — возможно более полно выявить все имеющиеся ограничения целостности и задать их в базе данных. Целостность БД не гарантирует достоверности содержащейся в ней информации, но обеспечивает по крайней мере правдоподобность этой информации, отвергая заведомо невероятные, невозможные значения. Таким образом, не следует путать целостность БД с достоверностью БД. Достоверность (или истинность) есть соответствие фактов, хранящихся в базе данных, реальному миру.
Правила целостности данных
К структурам контроля целостности данных относятся ограничители (constraint), которые привязаны к столбцам и триггеры (trigger), которые могут быть привязаны как к столбцам, так и к строкам в таблице.
Ограничители это элементарные проверки или условия, которые выполняются для операций вставки и модификации значения столбца. Если данная проверка не проходит или условие не выполняется, то вставка или модификация отменяется, а в программу клиента передается ошибка. SQL-серверы, как правило, поддерживают следующие ограничители.
NOT NULL - проверка на непустое значение. NULL - специальное понятие в СУБД, которое означает «пусто». «Пусто» и «0(ноль)» не равны друг другу!
UNIQUE - проверка на уникальность. Вставляемое значение должно быть уникально для данного столбца по всей таблице. Может содержать пустые значения.
PRIMARY KEY - первичный ключ. Значение в столбце считается первичным ключом, если оно непустое и уникально в пределах столбца данной таблицы. Первичный ключ может быть составным и представлять собой комбинацию столбцов. Тогда чтобы считаться первичным ключом, каждое из группы значений не должно быть пустыми и формируемые строки значений первичного ключа должны быть уникальны в пределах таблицы. Первичный ключ - основа для построения индексов по таблице.
FOREIGN KEY - внешний ключ. Назначает столбец или комбинацию столбцов в текущей (родительской) таблице в качестве внешнего ключа для ссылки из других таблиц.
REFERENCES - указатель ссылки (или родительский ключ). Указывает на столбец (комбинацию столбцов) в родительской таблице, ограничивающую значения в текущей (дочерней) таблице. CHECK - проверка фиксированного условия. В данном ограничителе явно указывается условие, которое должно выполняться для вставляемого или модифицируемого значения в столбце.
Например: check (user in 'ALEX','JUSTAS') - в столбце user могут содержаться только значения 'ALEX' и 'JUSTAS', попытка вставки значения 'SHTIRLITZ' будет интерпретирована как ошибочная , check (user_salary between 1000 and 5000) - столбец user_salary может принимать целочисленные значения в диапазоне от 1000 до 5000 и т.д. При формировании условий с некоторыми ограничениями могут использоваться функции, например check (user = upper(user)), в данном случае имя пользователя должно вводиться только в верхнем регистре. Есть и ограничения, например, CHECK не может содержать подзапросы (SELECT). Обычно ограничители задаются при создании таблиц. Но в дальнейшем их можно изменять, удалять или временно запрещать при помощи соответствующих команд СУБД.
Триггеры - это сохраненная откомпилированная процедура, которая связана с определенной таблицей. Триггеры, в отличие от ограничителей, могут выполнять сколь угодно сложные манипуляции над данными. Помимо операций модификации и вставки, триггеры могут срабатывать и при удалении данных из таблицы. Можно также задавать порядок срабатывания триггера относительно операции, т.е. выполниться ли триггер перед операцией вставки/модификации/удаления значения из столбца (или всей строки) или непосредственно после такой операции.
Некоторые типовые применения триггеров: • Прозрачный аудит (не зависящий от клиентских программ и невидимый для них) и регистрация событий, связанных с доступом к определенным таблицам или столбцам в таблицах. • Генерация значений в столбцах на основе значений в других столбцах при вставке/модификации строки данных. • Манипуляции над зависимыми таблицами в особенности, если они находятся на других узлах распределенной базы данных, чего нельзя сделать при помощи ограничителей.
Обработка данных в многопользовательской СУБД.
Основное требование к многопользовательским СУБД - обеспечение непротиворечивости данных в системе, при сохранении максимальной производительности и конкуренции в доступе к данным для пользователей.
Конкуренция в доступе к данным означает, что каждый из пользователей независим от остальных пользователей в потребности обработки данных. Система, во избежание порчи данных, самостоятельно устанавливает очередность работы с данными для пользователей. В случае необходимости пользователи могут ожидать своей очереди для работы с данными. Одной из главной целей многопользовательской СУБД является максимальное уменьшение этого времени ожидания до такой степени, чтобы оно (в идеале) стало незаметным для пользователя.
РБД состоит из набора узлов, связанных коммуникационной сетью, в которой:
• каждый узел — это полноценная СУБД сама по себе;
• узлы взаимодействуют между собой таким образом, что пользователь любого из них может получить доступ к любым данным в сети так, как будто они находятся на его собственном узле.
Каждый узел сам по себе является системой базы данных. Любой пользователь может выполнить операции над данными на своём локальном узле точно так же, как если бы этот узел вовсе не входил в распределённую систему. Распределённую систему баз данных можно рассматривать как партнёрство между отдельными локальными СУБД на отдельных локальных узлах.
Фундаментальный принцип создания распределённых баз данных («правило 0»): Для пользователя распределённая система должна выглядеть так же, как нераспределённая система.
Фундаментальный принцип имеет следствием определённые дополнительные правила или цели. Таких целей всего двенадцать:
1. Локальная независимость. Узлы в распределённой системе должны быть независимы, или автономны. Локальная независимость означает, что все операции на узле контролируются этим узлом.
2. Отсутствие опоры на центральный узел. Локальная независимость предполагает, что все узлы в распределённой системе должны рассматриваться как равные. Поэтому не должно быть никаких обращений к «центральному» или «главному» узлу с целью получения некоторого централизованного сервиса.
3. Непрерывное функционирование. Распределённые системы должны предоставлять более высокую степень надёжности и доступности.
4. Независимость от расположения. Пользователи не должны знать, где именно данные хранятся физически и должны поступать так, как если бы все данные хранились на их собственном локальном узле.
5. Независимость от фрагментации. Система поддерживает независимость от фрагментации, если данная переменная-отношение может быть разделена на части или фрагменты при организации её физического хранения. В этом случае данные могут храниться в том месте, где они чаще всего используются, что позволяет достичь локализации большинства операций и уменьшения сетевого трафика.
6. Независимость от репликации. Система поддерживает репликацию данных, если данная хранимая переменная-отношение — или в общем случае данный фрагмент данной хранимой переменной-отношения — может быть представлена несколькими отдельными копиями или репликами, которые хранятся на нескольких отдельных узлах.
7. Обработка распределённых запросов. Суть в том, что для запроса может потребоваться обращение к нескольким узлам. В такой системе может быть много возможных способов пересылки данных, позволяющих выполнить рассматриваемый запрос.
8. Управление распределёнными транзакциями. Существует 2 главных аспекта управления транзакциями: управление восстановлением и управление параллельностью обработки. Что касается управления восстановлением, то чтобы обеспечить атомарность транзакции в распределённой среде, система должна гарантировать, что все множество относящихся к данной транзакции агентов (агент — процесс, который выполняется для данной транзакции на отдельном узле) или зафиксировало свои результаты, или выполнило откат. Что касается управления параллельностью, то оно в большинстве распределённых систем базируется на механизме блокирования, точно так, как и в нераспределённых системах.
9. Аппаратная независимость. Желательно иметь возможность запускать одну и ту же СУБД на различных аппаратных платформах и, более того, добиться, чтобы различные машины участвовали в работе распределённой системы как равноправные партнёры.
10. Независимость от операционной системы. Возможность функционирования СУБД под различными операционными системами.
11. Независимость от сети. Возможность поддерживать много принципиально различных узлов, отличающихся оборудованием и операционными системами, а также ряд типов различных коммуникационных сетей.
12. Независимость от типа СУБД. Необходимо, чтобы экземпляры СУБД на различных узлах все вместе поддерживали один и тот же интерфейс, и совсем необязательно, чтобы это были копии одной и той же версии СУБД.
Типы распределённых баз данных
Распределённые базы данных
Мультибазы данных с глобальной схемой. Система мультибаз данных — это распределённая система, которая служит внешним интерфейсом для доступа ко множеству локальных СУБД или структурируется, как глобальный уровень над локальными СУБД.
Федеративные базы данных. В отличие от мультибаз не располагают глобальной схемой, к которой обращаются все приложения. Вместо этого поддерживается локальная схема импорта-экспорта данных. На каждом узле поддерживается частичная глобальная схема, описывающая информацию тех удалённых источников, данные с которых необходимы для функционирования.
Мультибазы с общим языком доступа — распределённые среды управления с технологией «клиент-сервер»
Классификация. Следует выделить два класса систем распределенной обработки и системы распределенных данных:
• системы распределенной обработки в основном отражают структуру и свойства многопользовательских операционных систем с базой данных, размещенной на центральном компьютере;
• системы распределенных данных обеспечивают обработку распределенных запросов, когда при обработке одного за¬проса используются информационные ресурсы, размещенные на различных ЭВМ сети. При этом, как и ранее, сле¬дует говорить как о распределенных файловых системах, так и о распределенных базах данных.
Для распределенных баз данных свойственны следующие ха¬рактеристики:
• база данных — это логически связанные, разделяемые на некоторое количество фрагментов данные;
• фрагменты распределяются по разным узлам, которые свя¬заны между собой сетевыми соединениями;
• может быть предусмотрена репликация фрагментов;
• доступ к данным на каждом узле происходит под управле¬нием СУБД, которая на каждом узле должна поддерживать работу как локальных приложений, так и глобальных.
Основные условия и требования к распределенной обработке данных:
• прозрачность относительно расположения данных (СУБД должна представлять все данные так, как если бы они были локальными);
• гетерогенность системы (СУБД должна работать с данны¬ми, которые хранятся в системах с различной архитектурой и производительностью);
• прозрачность относительно сети (СУБД должна одинаково работать в условиях разнородных сетей);
• поддержка распределенных запросов (пользователь должен иметь возможность объединять данные из любых баз, даже если они размещены в разных системах);
• поддержка распределенных изменений (пользователь дол¬жен иметь возможность изменять данные в любых базах, на доступ к которым у него есть права, даже если эти базы размещены в разных системах);
• поддержка распределенных транзакций (СУБД должна вы¬полнять транзакции, выходящие за рамки одной вычисли¬тельной системы, и поддерживать целостность распределенной БД даже при возникновении отказов как в отдель¬ных системах, так и в сети);
• безопасность (СУБД должна обеспечивать защиту всей рас¬пределенной БД от несанкционированного доступа);
• универсальность доступа (СУБД должна обеспечивать еди¬ную методику доступа ко всем данным).
Поясним некоторые из этих требований:
Прозрачность расположения. Прозрачный (для пользователя) доступ к удаленным данным предполагает использование в при¬кладных программах такого интерфейса с сервером БД, который позволяет переносить данные в сети с одного узла на другой, не требуя при этом модификации текста программы. Иными слова¬ми доступ к информационным ресурсам должен быть полно¬стью прозрачен относительно расположения данных.
Любой пользователь или любая прикладная программа опе¬рирует с одной или несколькими базами данных. В том случае, когда прикладная программа и сервер БД выполняются на од¬ном и том же узле, проблемы расположения не возникает. Для получения доступа к базе данных пользователю или программе достаточно указать имя базы, например: SQL Dbname.
Однако в том случае, когда прикладная программа запуска¬ется на локальном узле, а база данных находится на удаленном, возникает проблема идентификации удаленного узла. Для того чтобы получить доступ к базе данных на удаленном узле, необ¬ходимо указать имя удаленного узла и имя базы данных. Если использовать жестко фиксированное имя узла в паре «имя_узла, имя_БД», то прикладная программа становится за¬висимой от расположения БД. Например, обращение к БД «host:stock», где первый компонент — имя узла, будет зависимым от расположения.
Одно из возможных решений этой проблемы состоит в ис¬пользовании виртуальных имен узлов. Управление ими обеспе¬чивается специальным программным компонентом СУБД — сервером имен (Name Server), который адресует запросы клиен¬тов к серверам.
Прозрачность сети. Клиент и сервер взаимодействуют по сети с конкретной топологией; для поддержки взаимодействия всегда используется определенный протокол. Следовательно, оно должно быть организовано таким образом, чтобы обеспечивать независимость как от используемого сетевого аппаратного обеспечения, так и от протоколов сетевого обмена. Чтобы обеспечить прозрачный доступ пользователей и программ к удаленным данным в сети, объединяющей разнородные компьютеры, коммуникационный сервер должен поддерживать как можно R лее широкий диапазон сетевых протоколов (TCP/IP, DECnet SNA, SPX/IPX, NetBIOS, AppleTalk и др.).
Автоматическое преобразование форматов данных. Как толь ко несколько компьютеров различных моделей под управлением различных операционных систем соединяются в сеть, сразу воз¬никает вопрос о согласовании форматов представления данных Действительно, в сети могут быть компьютеры, отличающиеся разрядностью (16-, 32- и 64-разрядные процессоры), порядком следования байт в слове, представлением чисел с плавающей точкой и т. д. Задача коммуникационного сервера состоит в том чтобы на уровне обмена данными обеспечить согласование фор¬матов между удаленным и локальным узлами с тем, чтобы дан¬ные, извлеченные сервером из базы на удаленном узле и пере¬данные по сети, были правильно истолкованы прикладной про¬граммой на локальном узле.
Автоматическая трансляция кодов. В неоднородной компью¬терной среде при взаимодействии клиента и сервера возникает также задача трансляции кодов. Сервер может работать с одной кодовой таблицей (например, EBCDIC), клиент — с другой (на¬пример, ASCII), при этом происходит рассогласование трактов¬ки кодов символов. Поэтому, если на локальном узле использу¬ется одна кодовая таблица, а на удаленном — другая, то при пе¬редаче запросов по сети и при получении ответов на них необходимо обеспечить трансляцию кодов. Решение этой задачи также ложится на коммуникационный сервер.
Однако ни одна из существующих СУБД не дос¬тигает этого идеала вследствие следующих практических проблем:
• низкая и несбалансированная производительность сетей передачи данных, что в распределенных транзакциях силь¬но снижает общую производительность обработки;
• обеспечение целостности данных в распределенных тран¬закциях базируется на принципе «все или ничего» и требу¬ет специального протокола двухфазного завершения тран¬закций, что приводит к длительной блокировке изменяе¬мых данных;
• необходимо обеспечить совместимость данных стандартно¬го типа, для хранения которых в разных системах исполь¬зуются разные физические форматы и кодировки;
• трудности выбора схемы размещения системных каталогов. Если каталог будет храниться в одной системе, то удален¬ный доступ будет замедлен. Если будет размножен, то из¬менения придется распространять и синхронизировать;
• необходимо обеспечить совместимость СУБД разных типов и поставщиков;
• увеличение потребностей в ресурсах для координации ра¬боты приложений с целью обнаружения и устранения ту¬пиковых ситуаций в распределенных транзакциях.
Типы распределенных СУБД
В общем случае режимы работы с БД можно классифициро¬вать по следующим признакам:
• многозадачность — однопользовательский или многополь¬зовательский;
• правило обслуживания запросов — последовательное или параллельное;
• схема размещение данных — централизованная или рас¬пределенная БД.
Распределенные СУБД подразделяются на однородные и раз¬нородные.
В однородных системах все узлы используют один и тот же тип СУБД. В разнородных системах на узлах могут функциони¬ровать различные типы СУБД, использующие разные модели данных. Однородные системы значительно проще проектировать и сопровождать, добавляя новые узлы к уже существующей рас¬пределенной системе и повышая производительность системы за счет параллельной обработки информации.
Разнородные системы обычно возникают в тех случаях, когда узлы, уже эксплуатирующие свои собственные системы с базами данных, со временем интегрируются в распределенную систему. В разнородных системах для организации взаимодействия между различными типами СУБД требуется обеспечить преобразование предаваемых сообщений, для чего каждый из узлов должен иметь возможность формулировать запросы на языке той СУБД, которая используется на их локальном узле или система должна взять на себя выполнение всех необходимых преобразований.
Очевидны следующие преимущества и недостатки распределенных баз данных (табл. 7.1).
Распределенная СУБД должна иметь следующий набор функциональных возможностей:
• расширенные службы установки соединений должны обес¬печивать доступ к удаленным узлам и позволять передавать запросы и данные между узлами, входящими в сеть;
• расширенные средства ведения каталога, позволяющие со¬хранять сведения о распределении данных в сети;
• средства обработки распределенных запросов, включая ме¬ханизмы оптимизации запросов и организации удаленного доступа к данным;
• расширенные функции управления защитой, позволяющие обеспечить соблюдение правил авторизации и прав доступа к распределенным данным;
• расширенные функции управления параллельным выпол¬нением, позволяющие поддерживать целостность копируе¬мых данных;
• расширенные функции восстановления, учитывающие ве¬роятность отказов в работе отдельных узлов и отказов ли¬ний связи.
Соответственно, программные средства, обеспечивающие целевую (функциональную) обработку данных, должны быть ор¬ганизованы таким образом, чтобы обеспечить более эффектив¬ное использование совокупных вычислительных ресурсов за счет специализированного разделения функций обработки между центральным процессом СУБД и клиентскими функциональ¬но-ориентированными процедурами.
Це?лостность ба?зы да?нных (database integrity) — соответствие имеющейся в базе данных информации её внутренней логике, структуре и всем явно заданным правилам. Каждое правило, налагающее некоторое ограничение на возможное состояние базы данных, называется ограничением целостности (integrity constraint). Примеры правил: вес детали должен быть положительным; количество знаков в телефонном номере не должно превышать 25; возраст родителей не может быть меньше возраста их биологического ребёнка и т.д.
Задача аналитика и проектировщика базы данных — возможно более полно выявить все имеющиеся ограничения целостности и задать их в базе данных. Целостность БД не гарантирует достоверности содержащейся в ней информации, но обеспечивает по крайней мере правдоподобность этой информации, отвергая заведомо невероятные, невозможные значения. Таким образом, не следует путать целостность БД с достоверностью БД. Достоверность (или истинность) есть соответствие фактов, хранящихся в базе данных, реальному миру.
Правила целостности данных
К структурам контроля целостности данных относятся ограничители (constraint), которые привязаны к столбцам и триггеры (trigger), которые могут быть привязаны как к столбцам, так и к строкам в таблице.
Ограничители это элементарные проверки или условия, которые выполняются для операций вставки и модификации значения столбца. Если данная проверка не проходит или условие не выполняется, то вставка или модификация отменяется, а в программу клиента передается ошибка. SQL-серверы, как правило, поддерживают следующие ограничители.
NOT NULL - проверка на непустое значение. NULL - специальное понятие в СУБД, которое означает «пусто». «Пусто» и «0(ноль)» не равны друг другу!
UNIQUE - проверка на уникальность. Вставляемое значение должно быть уникально для данного столбца по всей таблице. Может содержать пустые значения.
PRIMARY KEY - первичный ключ. Значение в столбце считается первичным ключом, если оно непустое и уникально в пределах столбца данной таблицы. Первичный ключ может быть составным и представлять собой комбинацию столбцов. Тогда чтобы считаться первичным ключом, каждое из группы значений не должно быть пустыми и формируемые строки значений первичного ключа должны быть уникальны в пределах таблицы. Первичный ключ - основа для построения индексов по таблице.
FOREIGN KEY - внешний ключ. Назначает столбец или комбинацию столбцов в текущей (родительской) таблице в качестве внешнего ключа для ссылки из других таблиц.
REFERENCES - указатель ссылки (или родительский ключ). Указывает на столбец (комбинацию столбцов) в родительской таблице, ограничивающую значения в текущей (дочерней) таблице. CHECK - проверка фиксированного условия. В данном ограничителе явно указывается условие, которое должно выполняться для вставляемого или модифицируемого значения в столбце.
Например: check (user in 'ALEX','JUSTAS') - в столбце user могут содержаться только значения 'ALEX' и 'JUSTAS', попытка вставки значения 'SHTIRLITZ' будет интерпретирована как ошибочная , check (user_salary between 1000 and 5000) - столбец user_salary может принимать целочисленные значения в диапазоне от 1000 до 5000 и т.д. При формировании условий с некоторыми ограничениями могут использоваться функции, например check (user = upper(user)), в данном случае имя пользователя должно вводиться только в верхнем регистре. Есть и ограничения, например, CHECK не может содержать подзапросы (SELECT). Обычно ограничители задаются при создании таблиц. Но в дальнейшем их можно изменять, удалять или временно запрещать при помощи соответствующих команд СУБД.
Триггеры - это сохраненная откомпилированная процедура, которая связана с определенной таблицей. Триггеры, в отличие от ограничителей, могут выполнять сколь угодно сложные манипуляции над данными. Помимо операций модификации и вставки, триггеры могут срабатывать и при удалении данных из таблицы. Можно также задавать порядок срабатывания триггера относительно операции, т.е. выполниться ли триггер перед операцией вставки/модификации/удаления значения из столбца (или всей строки) или непосредственно после такой операции.
Некоторые типовые применения триггеров: • Прозрачный аудит (не зависящий от клиентских программ и невидимый для них) и регистрация событий, связанных с доступом к определенным таблицам или столбцам в таблицах. • Генерация значений в столбцах на основе значений в других столбцах при вставке/модификации строки данных. • Манипуляции над зависимыми таблицами в особенности, если они находятся на других узлах распределенной базы данных, чего нельзя сделать при помощи ограничителей.
Обработка данных в многопользовательской СУБД.
Основное требование к многопользовательским СУБД - обеспечение непротиворечивости данных в системе, при сохранении максимальной производительности и конкуренции в доступе к данным для пользователей.
Конкуренция в доступе к данным означает, что каждый из пользователей независим от остальных пользователей в потребности обработки данных. Система, во избежание порчи данных, самостоятельно устанавливает очередность работы с данными для пользователей. В случае необходимости пользователи могут ожидать своей очереди для работы с данными. Одной из главной целей многопользовательской СУБД является максимальное уменьшение этого времени ожидания до такой степени, чтобы оно (в идеале) стало незаметным для пользователя.
Соседние файлы в папке Smirnov