Введение в системы БД (542480), страница 199
Текст из файла (страница 199)
Иначе говоря, на каждом узле есть собственные локальные "реальные" базы данных, собственные локальные пользователи, собственные локальные СУБД и программное обеспечение управления транзакциями (включая собственные локальные системы блокировки, ведения журналов, восстановления и т.д.) и собственный локальный менеджер передачи данных. В частности, любой пользователь может выполнить операции над данными на своем локальном узле точно так же, как если бы этот узел вовсе не входил в распределенную систему (по крайней мере, так должно быть).
Распределенную систему баз данных можно рассматривать как некоторое партнерство между отдельными локальными СУБД на отдельных локальных узлах. Новый программный компонент на каждом узле — логическое расширение локальной СУБД вЂ” предоставляет необходимые функциональные возможности для организации подобного партнерства. Именно этот компонент вместе с сушествуюшими СУБД составляет то, что обычно называется распределенной системой управления базами данных (РСУБД). 768 Часть К Дополните,талые аспекты Чаше всего предполагается, что узлы физически распределены (а возможно, и географически, как показано на рис. 20.1), хотя в действительности достаточно того, чтобы они были распределены лоеически.
Два "узла" могут даже сосуществовать на одной и той же машине 1в особенности на начальном этапе тестирования). Главная цель создания распределенных систем со временем изменялась. В ранних исследованиях в основном предполагалась географическая распределенность, но в большинстве первых коммерческих реализаций предполагалось локальное распределение, когда несколько "узлов" размешалось в одном здании и соединялось с помощью локальной сети (ЛВС). Однако позже стремительное распространение глобальных сетей (ГВС) снова пробудило интерес к возможности географического распределения. В любом случае это не имеет большого значения с точки зрения системы баз данных — решать, в основном, требуется одни и те же технические (связанные с базами данных) проблемы.
Поэтому в настоящей главе мы можем обоснованно рассматривать представленную на рис 20.1 систему как типичного представителя распределенных систем. Замечание. Для упрощения изложения будем предполагать, если нет соответствующего явного указания, что система однородна. Однородна в том смысле, что на каждом узле работает некоторая копия одной и той же СУБД. Будем называть это предположением о строгой однородности.
Возможности и особенности неоднородных систем будут проанализированы в разделе 20.6. Преимущества Зачем нужны распределенные базы данных? Основная причина заключается в том, что предприятия обычно уже распределены. Распределены по крайней мере логически, т.е. разделены на подразделения, отделы, рабочие группы и т.д. Очень часто они распределены и физически, т.е, разделены на заводы, фабрики, лаборатории и т.д. Из этого следует, что данные также обычно распределены, поскольку каждая организационная единица создает и обрабатывает собственные данные, относящиеся к деятельности этой единицы. Таким образом, информация предприятия разбивается на части, которые иногда называют островачи информачии. А распределенная система обеспечивает.посты для их соединения в единое целое.
Иначе говоря, распределенная система позволяет структуре базы данных отображать структуру предприятия — локальные данные могут храниться локально, в соответствии с логической принадлежностью, тогда как к удаленным данным доступ может осуществляться по мере необходимости.
Для того чтобы лучше в этом разобраться, приведем пример. Рассмотрим еще раз рис. 20.1. Для простоты предположим, что есть только два узла, Лос-Анджелес и СанФранциско, и что наша система — это банковская система. Данные о счетах ЛосАнджелеса хранятся в Лос-Анджелесе, а данные о счетах Сан-Франциско — в СанФранциско. Преимущества подобной распределенной системы очевидны: эффективность обработки (данные хранятся в том месте, где доступ к ним требуется наиболее часто) плюс расширенные возможности доступа (при необходимости с помощью коммуникационной сети из Сан-Франциско можно получить доступ к счетам Лос-Анджелеса и наоборот). Пожалуй, наиболее важным преимуществом распределенных систем является, как уже было отмечено, отражение ими структуры предприятия.
Конечно, существует множество других преимушеств, которые будут обсуждаться ниже в этой главе вместе с соответствующими аспектами. Однако следует отметить, что подобным системам свойствен и ряд недостатков, наиболее существенным из которых является повышенная слож- 769 Глава 20. Распределенные базы данньп ность распределенных систем, по крайней мере с технической точки зрения. В идеальном случае, конечно, эта сложность должна быть проблемой реализации, а не проблемой пользователя, но вполне возможно, что на практике некоторые ее аспекты все-таки будут видны конечным пользователям. Для того чтобы скрыть от пользователя сложность системы, требуется весьма тшательная ее проработка.
Примеры распределенных систем Для ссылок в дальнейшем мы кратко перечислим некоторые известные реализации распределенных систем. Сначала — прототипы. Среди многочисленных исследовательских систем наиболее известны три системы. Во-первых, система ЯЮ-1, созданная в научно-исследовательском отделении корпорации Сошрцгег Согрогайоп оГ Ашег)са в конце 70-х и начале 80-х годов [20.34]. Во-вторых, система Кв (читается "К-зшг"), распределенная версия системы-прототипа Буз!егп К, созданная в исследовательском отделе компании 1ВМ в начале 80-х годов [20.39]. И в-третьих, система !3!з!г!Ьцгед! пйгез, распределенная версия прототипа системы !пйгез, созданная также в начале 80-х годов в Калифорнийском университете в Беркли [20.36].
Что касается коммерческих реализаций, то большинство современных Я И:продуктов включает определенную поддержку распределенных баз данных, но, конечно, с разными уровнями функциональных возможностей. Наиболее известные среди них следующие: 1пйгез!Бгаг (распределенный компонент базы данных СУБД !пйгез), версия для распределенных баз данных СУБД Огас!е и средства распределения данных для СУБД РВ2. Заиечание.
Безусловно, эти два списка не претендуют на полноту. Их назначение— лишь указать системы, которые по тем или иным причинам оказывали или оказывают определенное влияние на развитие данной области либо представляют интерес благодаря своей внутренней структуре. Также следует отметить, что все перечисленные выше системы, как прототипы, так и коммерческие продукты, являются реляционными (по крайней мере, в них поддерживается язык Я!)Ь). В действительности сушествует несколько конкретных причин, по которым для успешной реализации распределенная система должна быть реляционной. Реляционная технология — это необходимое условия для эффективной распределенной технологии (20.15].
Некоторые причины такого положения дел будут рассмотрены ниже в этой главе. Фундаментальный принцип Теперь сформулируем утверждение, которое может рассматриваться как фундаментальный принцип создания распределенных баз данных [20.14]. ° Для пользователя распределенная система должна выелядеть так же, как не- распределенная система. Другими словами, пользователи распределенной системы должны иметь возможность действовать так, как если бы система не была распределена. Все проблемы распределенных систем относятся илн должны относиться к внутренним проблемам или проблемам реализации, а не к внешним проблемам или проблемам пользовательского уровня. Замечание.
Понятие "пользователи" в предыдущем абзаце относится к пользователям (конечным пользователям или прикладным программистам), выполняюшим операции обработки данных. Все операции л<анипулирования данными должны оставаться логиче- 770 Часть 1'. Дополнительные аспекты ски неизменными.
Но для операции определения данных, напротив, в распределенной системе обязательно потребуются некоторые дополнения. Например, пользователь на узле Х должен иметь возможность указать, что данная переменная-отношение будет разделена на "фрагменты", которые будут храниться на узлах з и 8 (см. обсуждение фрагментации в следуюшем разделе). Сформулированный выше фундаментальный принцип имеет следствием определенные дополнительные правила или цели'.
Таких целей всего двенадцать, и каждая из них будет рассмотрена в следуюшем разделе. Для последующих ссылок перечислим эти цели. 1. Локальная независимость. 2. Отсутствие опоры на центральный узел. 3. Непрерывное функционирование. 4. Независимость от расположения. 5.
Независимость от фрагментации. б. Независимость от репликации. 7. Обработка распределенных запросов. 8. Управление распределенными транзакциями. 9. Аппаратная независимость. 10. Независимость от операционной системы. !!. Независимость от сети. 12. Независимость от типа СУБД. Обратите внимание, что не все эти цели независимы одна от другой. Кроме того, они недостаточно исчерпываюшие и не все одинаково важны (разные пользователи могут придавать различное значение разным целям в различных средах, и, кроме того, некоторые из этих целей могут быть вообше неприменимы в некоторых ситуациях). Однако данные цели полезны как основа для понимания самой распределенной технологии и как обшая схема описания функциональных возможностей конкретных распределенных систем.
Поэтому мы будем использовать список этих целей как организационный принцип для большей части данной главы. В разделе 20.3 кратко обсуждается каждая из целей. В разделе 20.4 некоторые конкретные вопросы рассматриваются более подробно, а в разделе 20.5, как уже отмечалось, приводится обсуждение систем "клиент!сервер". В разделе 20.6 мы детачьно обсудим некоторые конкретные проблемы, связанные с достижением независимости от СУБД. И наконец, раздел 20.7 посвящен поддержке языка БОЬ, а в разделе 20.8 представлены резюме и несколько заключительных замечаний. И последний дополнительный вопрос в этом разделе.
Важно отличать истинные обобщенные системы распределенных баз данных от систем, которые предоставляют просто удаленный доступ к данным (кстати, это все, что на самом деле предоставляет пользователям система "клиент/сервер"). В системах удаленного доступа к данным конечный пользователь может оперировать данными на удаленном узле или даже данными I "Правила" — эта термин, используемый в статье, в которой эти правила впервые были првдставлены (лО.!4/. нФундаивнтальный принцип" бьм назван "Правилом Нуяь". Однако на самом деле здесь более улзвствн термин "цели" — "правила" звучит слишком капэвгарична. В этой главе будет игпальзаватьсл более улэвреннаг "цели". 771 Глава 20. Распределенные базы данньп на нескольких удаленных узлах одновременно, но ему будут видны все "швы".
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
