Распределенные информационные системы и сети

Главная > Документ

РАСПРЕДЕЛЕННЫЕ ИНФОРМАЦИОННЫЕ СИСТЕМЫ

Ю.А. Илларионов

ГЛАВА 1. АНАЛИЗ СОСТОЯНИЯ РАЗВИТИЯ ОСНОВНЫХ КОНЦЕПЦИЙ И АЛГОРИТМОВ УПРАВЛЕНИЯ ДЛЯ РАСПРЕДЕЛЁННЫХ ВЫЧИСЛИТЕЛЬНЫХ СИСТЕМ НА БАЗЕ ЛОКАЛЬНЫХ СЕТЕЙ. 1.1. Определение области исследования. Распределённой вычислительной системой (РВС) будем называть систему, состоящую из двух компонентов: множества электронно вычислительных машин (ЭВМ) и сети связи (или сети передачи данных), объединяющей все ЭВМ, входящие в РВС. Всю полезную обработку информации производят вычислительные процессы, выполняющиеся на хост ЭВМ . Всю обработку информации, связанную с необходимостью её передачи через сеть связи, выполняют процессы, расположенные на коммуникационных ЭВМ .Коммуникационные ЭВМ необходимы в сетях связи, имеющих сложную многосвязную топологию, при условии, что прямые физические соединения (каналы) между взаимодействующими посредством передачи информации хост ЭВМ отсутствуют. Таким образом, учитывая, что для эффективной обработки информации в РВС необходимо не только эффективно её обрабатывать на хост ЭВМ , но и эффективно (т.е. с наименьшими задержками) передавать её через сеть связи, работы в области РВС разделились на две группы: 1. Работы в области организации взаимодействия вычислительных процессов в РВС. В этих работах предполагается, что сеть связи уже существует и удовлетворяет определённым требованиям, выдвигаемым к ней. Таким образом, остаётся только решить задачу организации взаимодействия вычислительных процессов, учитывая, что:

в РВС существует множество вычислительных процессов; в РВС существует множество вычислительных ресурсов; процессы и ресурсы могут располагаться на разных хост ЭВМ; процессы могут выполняться параллельно; в системе существует конкуренция распределённых параллельных процессов за ресурсы ЭВМ; в РВС существует неоднородность хост ЭВМ и их оперативных систем; существует тенденция к децентрализации управления взаимодействием вычислительных процессов в РВС с целью повышения надёжности последних. 2. Работы в области организации процессов передачи информации через сети связи. Для этих работ характерно представление о сети как о множестве портов ввода вывода, между которыми существуют логические соединения. Кто поставляет информацию в эти порты и кто её оттуда забирает, не является в данном случае объектом исследования. Задача состоит только в том, как наиболее эффективно осуществить передачу информации по сети связи от одного порта к другому, при условии, что:

соединения между портами не являются фиксированными, и структура логических связей в сети может динамически изменяться; сеть может иметь многосвязную топологию, в которой отсутствуют непосредственные физические соединения между портами; информация в процессе передачи может искажаться; потоки информации, включая их объём и направление, заранее не определены; для организации передачи информации через сеть связи требуется организовать разделение коммуникационных ресурсов между потоками информации в условиях недостатка этих ресурсов; управление разделением коммуникационных ресурсов имеет тенденцию к децентрализации. Настоящая диссертация относится к работам первой группы и посвящена только вопросам организации взаимодействия вычислительных процессов в РВС. Определим область исследования более точно. Учитывая, что с точки зрения возможностей технических средств РВС в основном различаются по применяемым в них сетям связи, распределённые системы можно разбить на две большие группы: РВС, построенные на базе сетей с маршрутизацией и РВС, построенные на базе сетей с селекцией информации, или сетей с общим каналом связи. Настоящая работа посвящена вопросам организации разделения вычислительных ресурсов в РВС, предназначенных для управления производственными процессами в реальном времени и построенных на базе локальных сетей связи с децентрализованным приоритетным управлением доступом к общему каналу. Вопросы децентрализованного приоритетного управления доступом (ДПУ) рассмотрены в работах. В этих же работах впервые была высказана мысль о том, что наличие средств ДПУ и средств обработки информации непосредственно в общем канале в процессе передачи может по новому организовать управление взаимодействием распределённых вычислительных процессов в РВС. Другими словами, локальные сети с ДПУ можно рассматривать не только как систему связи, но и как дополнительное средство управления распределёнными системами. Однако, этот вопрос не был до конца исследован. Итак, основной целью настоящей работы является исследование вопросов разделения ресурсов РВС между вычислительными процессами в условиях существующей распределённости как ресурсов, так и процессов, при наличии множества параллельно возникающих в неопределённые моменты заявок на использование ресурсов; на основании проведённых исследований в работе должны быть разработаны новые высокоскоростные алгоритмы разделения ресурсов для РВС, построенных на базе локальных сетей с ДПУ и средствами вычислений в общем канале (ВОК).Как уже было отмечено, исследования будут вестись в области РВС для промышленного применения, т.е. для систем реального времени. С точки зрения вычислительных мощностей этой системы, построенные в основном на базе микропроцессорной техники, поэтому в дальнейшем будем называть такие РВС распределёнными микропроцессорными управляюще вычислительными системами (РМУВС). Учитывая существующие особенности сетей связи для исследуемых систем, проанализируем эти особенности в сравнении с другими известными сетями.1.2. Особенности локальных сетей с децентрализованным приоритетным управлением доступом к каналу. Первые публикации, посвящённые принципам передачи информации через общий канал связи в режиме его разделения многими абонентами (с точки зрения сети, абонент – это хост ЭВМ, имеющая доступ к каналу через сетевой контроллер; в более широком смысле абонентом может быть и отдельный процесс, выполняемый на хост ЭВМ), появились в начале 70 х годов. К этому моменту был накоплен достаточно большой опыт по созданию РВС на базе глобальных сетей, и это отразилось на решениях, которые в дальнейшем были использованы в РВС на базе локальных сетей (или локальных РВС ЛРВС). В некоторых работах до сих пор не делается различия между организацией управления в глобальных РВС и ЛРВС, а считается, что эти два класса различаются только по протяжённости их линий связи. Появление стандартов IEEE 802 и ECMA внесло некоторую ясность в этот вопрос, однако только в отношении организации связи с ЛРВС. Поэтому в большинстве работ, посвящённых организации взаимодействия вычислительных процессов в ЛРВС, не учитывается специфика таких систем, которая будет отражена ниже. Однако, ряд авторов считает, что ЛРВС в их современном понимании являются системами, по своим архитектурным особенностям приближающимся скорее к многопроцессорным системам, чем к «вычислительным сетям» в их традиционном понимании. В особенности это относится к исследуемым в настоящей работе системам – ряд отличительных признаков позволяет рассматривать их как совершенно новый класс РВС, построенных на базе локальных сетей связи с уникальными возможностями, недоступными в других распределённых системах. Отметим основные архитектурные особенности локальных сетей связи с ДПУ и ВОК, которые будут иметь значение в дальнейшем исследовании.

Наличие общего высокоскоростного канала связи. Наличие общего канала делает локальную связь вырожденной, т.к. в такой сети нет необходимости производить основную сетевую процедуру – маршрутизацию пакетов при передаче информации. Кроме того, как будет показано в дальнейшем, наличие общего канала в соединении с ДПУ и ВОК позволяют использовать канал не только как средство передачи информации, но и как эффективное средство управления распределённой системой. Высокая скорость передачи информации по каналу позволяет строить сетевые протоколы, используя заголовки довольно большой длины для упрощения протоколов. Другими словами, при такой скорости нет необходимости в минимизации длины передаваемых пакетов. Большие пакеты позволяют перейти к методу коммутации сообщений, более простому с точки зрения организации системного программного обеспечения на транспортном уровне. Кроме того, возможность передачи заголовков большой длины позволяет, как будет показано в дальнейшем, использовать в ЛРВС принципиально новые способы обмена информацией, отличающиеся более высокой эффективностью и простой реализацией по сравнению с существующими. Управление доступом к каналу. Механизм управления доступом к каналу во многом определяет характеристики локальных сетей связи. Однако, до последнего времени исследовалось в основном влияние способов управления доступом на пропускную способность канала. Вместе с тем, как отмечалось в работах механизм управления доступом оказывает гораздо большее влияние на ЛРВС. В частности, применение ДПУ позволяет решить на низких уровнях ряд задач, которые традиционно решались на верхних уровнях при помощи обмена сообщениями. Вместе с тем, исследования в этой области только начинаются. Вычисления в общем канале. Алгоритмы вычислений в общем канале (ВОК) предложены в работах. Суть их состоит в том, что информация, проходящая по каналу связи, может быть обработана абонентами распределённой системы без задержки на её обработку. Применение ВОК позволяет осуществлять в ЛРВС групповую обработку информации всеми абонентами в процессе её передачи и даёт возможность получения группового ответа от всех абонентов за одну пересылку информации по каналу, что недоступно в других распределённых системах. Перечисление особенности сетей связи с ДПУ и ВОК даёт основания считать, что ЛРВС, построенные на базе таких сетей, нельзя рассматривать как «те же большие вычислительные сети, только маленькие», хотя вообще такая позиция в настоящее время широко распространена. Перейдём к рассмотрению основных задач и концепций управления в распределённых системах.1.3. Основные задачи и концепции управления в распределённых вычислительных системах. Основной задачей управления в любой вычислительной системе является задача разделения ресурсов в условиях недостатка последних. В РВС задача разделения имеет свои особенности, связанные с распределением ресурсов и процессов по различным абонентам системы. Перечислим эти особенности.

Поскольку в РВС входит множество ЭВМ, то каждая из них может иметь свои ресурсы, доступные для процессов, выполняющихся как локально (т.е. на этой же ЭВМ), так и удалённо (т.е. на другой ЭВМ). Если ресурс является локальным (т.е. полностью принадлежит отдельной ЭВМ), то ответственность за корректную синхронизацию процессов при доступе к такому ресурсу полностью возлагается на эту ЭВМ. В этом случае проблемы синхронизации не возникает, если ресурс является монопольно используемым. Если же ресурс является коммунальным, то в РВС возникает проблема разделения такого ресурса из за того, что если в сосредоточенных централизованных системах большинство накладных расходов на организацию разделения (т.е. выделение памяти для буферов и т.д.) берут на себя сами процессы по принципу «кому нужно, тот и платит», то в РВС эти расходы возлагаются на обслуживающую ЭВМ и получается, что «кто обслуживает, тот ещё и платит». В РВС ресурс может быть организован таким образом, что для решения о его предоставлении некоторому процессу необходимо коллективное согласие всех ЭВМ, которым принадлежат отдельные части такого ресурса, называемого распределённым. Эта задача возникла первоначально в распределённых базах данных, в которых для обеспечения высокой надёжности хранения информации применялось её многократное копирование и распределение копий по системе. Возникающая при этом задача синхронизации при обновлении многих копий распределённой информации является базовой задачей распределённого управления в РВС, и от эффективности её решения зависит в конечном итоге эффективность управления в целом. Традиционно в любых вычислительных системах управление разделением ресурсов возлагается на системное программное обеспечение – операционные системы (ОС). Для РВС это также справедливо – подобное программное обеспечение называется распределёнными операционными системами (РОС). Несмотря на большое разнообразие существующих в настоящее время РОС и различие в применяемых в них алгоритмов управления, их можно классифицировать на основании нескольких базовых моделей, приводимых ниже.Модель МРММ (много ресурсов – много мониторов). Основной идеей, положенной в основу этой модели, является принцип автономности, согласно которому любая ЭВМ, входящая в РОС, является «хозяином» своих собственных локальных ресурсов и только она имеет право решать задачу их разделения. При таком подходе на каждой ЭВМ имеется процесс, являющийся монитором ресурсов этой ЭВМ. Все остальные процессы связаны с мониторами посредством механизма обмена сообщениями через транспортную сеть согласно семиуровневой архитектуре |SO/OSI.Модель МРММ является моделью вычислительной сети в её традиционном понимании; системы, построенные в соответствии с этой моделью, предназначены в основном для реализации «электронной почты» и организации доступа к ресурсам удалённых ЭВМ. Задача управления разделением распределённых ресурсов в таких системах не решается.Модель МРОМ (много ресурсов – один монитор). Полностью централизованная модель. В систему вводится центральный процесс, являющийся монитором всей системы и в частности, монитором распределённых ресурсов. Все остальные процессы имеют доступ к мониторам только посредством обращения к центральному монитору. Управление разделением распределённых ресурсов в этом случае не составляет трудности, но введение центрального процесса резко снижает надёжность работы РВС. Поэтому централизованные способы управления применяются, как правило, только в самых простых распределённых системах, не предназначенных для ответственных применений.Модель ОРММ (один ресурс – много мониторов). Модель основана на предположении, что в системе имеется ресурс, надёжность которого намного больше, чем надёжность любого монитора. В действительности, как уже было сказано, такие ресурсы образуются за счёт копирования наиболее важных системных ресурсов и распределения копий по различным абонентам РВС; причём каждая копия имеет свой монитор. Считывать информацию можно параллельно с любой работоспособной копии ресурса, обновлять информацию необходимо на всех копиях. В этих условиях при обновлении информации все мониторы копий должны взаимодействовать с целью с целью принятия коллективного решения о предоставлении ресурса для операции обновления или записи. Такие РВС называются системами с распределённым (децентрализованным коллективным) управлением; их развитию и посвящена настоящая работа. Ключевым вопросом для таких систем является проблема синхронизации мониторов при выработке или коллективного решения. В зависимости от методов, используемых в настоящее время для синхронизации мониторов, РВС этого класса можно разбить на две группы. В РВС первой группы мониторы взаимодействуют, обмениваясь сообщениями через транспортную сеть. Основное достоинство подобных систем состоит в том, что алгоритмы синхронизации мониторов в этом случае не зависят от структуры сети (топологии, методов доступа и т.д.) и могут быть использованы в любых РВС. Однако, как будет показано в дальнейшем, алгоритмы этого класса требуют пересылки значительного количества сообщений через транспортную сеть, что приводит к большим временным расходам на синхронизацию. При оценке эффективности алгоритмов следует учитывать то, что накладные расходы на пересылку одного сообщения через транспортную сеть составляют около 20 мс для широкого круга распределённых систем. Тем не менее, такой подход к синхронизации широко используется из за отсутствия в настоящее время подходящих альтернативных способов для сетей ЭВМ. В РВС второй группы для синхронизации мониторов применяются специально выделенные линии связи, по которым возможна передача только синхронизирующей управляющей информации (импульсов, потенциалов на линиях и т.д.). Такой принцип используется в мультимикропроцессорных системах с сетевой организацией, имеющих небольшую протяжённость линий связи. Однако для РВС на базе локальных сетей большой протяжённости (до 2 км) такой подход неприемлем из за значительного увеличения кабельной продукции, поскольку число линий синхронизации может зависеть как от числа распределённых продуктов, так и от числа абонентов системы. Перейдём к рассмотрению известных алгоритмов разделения ресурсов в РВС с распределённым управлением.1.4. Алгоритмы разделения ресурсов для систем с распределённым управлением. Все алгоритмы разделения ресурсов для систем с распределённым управлением можно разбить на три группы: алгоритмы с использованием голосования, алгоритмы с использованием предварительной блокировки и алгоритмы с циркулирующей привилегией.Алгоритмы с использованием голосования основаны на процессе обмена сообщениями между процессами контроллерами с целью прихода к соглашению относительно последовательности транзакций в распределённой системе. Под транзакцией понимается последовательность операций чтения информации из некоторой базы данных, обновления (изменения) считанной информации и записи обновлённой информации в базу данных. Если голосования и выполнение транзакций производителя одними и теми же контроллерами, то голосование называется синхронным; если разными, то голосование называется асинхронным. В алгоритме синхронного голосования контроллер, контроллер, принявший запрос на транзакцию, присоединяет тег – временной штамп из сообщения, содержащего суть запроса и идентификатор пославшего запрос абонента. Далее, если не было инициировано голосование предыдущей транзакции, этот контроллер посылает широковещательное сообщение со своим голосом всем остальным контроллерам (рис. 1.1.). Если предположить, что можно отличить более высокий приоритет некоторой транзакции Т а от приоритета транзакции Т с, то система из трёх контроллеров будет работать следующим образом. 1. Контроллер В: если голос для транзакции Т с принят раньше, чем некоторый голос для Т а, то контроллер В широковещательно посылает свой голос, отдавая его Т с (рис. 1.1а.). При получении запроса на транзакцию Т а В уничтожает Т с и широковещательно отдаёт свой голос транзакции Т а (рис. 1.1б.). Если голос за транзакцию Т а принят раньше, В сразу отдаёт свой голос за Т а, отбрасывая голоса за Т с, пришедшие позднее.Рис 1.1. 2. Контроллер С: отдаёт свой голос за Т а при приёме голоса за Т а. 3. Контроллер А: отбрасывает все голоса за Т с. После приёма голосов от всех контроллеров за одну и ту же транзакцию (в рассмотренном случае Т а) каждый из контроллеров начинает выполнение этой транзакции. В другом алгоритме синхронного голосования явно выделяется инициирующий контроллер. Если транзакция поступила к контроллеру на выполнение (т.е. от пользователя), то этот контроллер инициирует голосование, посылая запрос на начало голосования остальным контроллерам. Если все остальные контроллеры ответят на этот запрос передачей сообщения АСК + , то транзакция принимается и инициирующий контроллер широковещательно посылает UPD сообщение для локальных инициаций транзакции всеми остальными контроллерами. Контроллеры, закончившие локальное выполнение транзакции (или вообще не начинавшие её выполнение) сигнализируют ответом END инициатору. После приёма END – сообщений от всех контроллеров, инициатор переходит в начальное состояние. Контроллеры, завершившие очередную транзакцию, также переходят в начальное состояние и готовы для новых транзакций. Каждый из контроллеров, приняв запрос на новую транзакцию, может начать её выполнение только в том случае, если она совместима с текущей транзакцией, выполняемой контроллером. Только в этом случае сообщение АСК + может быть послано инициатору, и начаться выполнение новой транзакции после приёма UPD. Транзакции считаются совместимыми, если они запрашивают различные наборы чтения и записи для своего выполнения. Приоритеты транзакций различаются согласно алгоритму, приведённому в работе.На рис. 1.2. показано, как различается конфликт в том случае, когда две совместимые транзакции инициируют запрос на голосование. Контроллеры А и С голосуют за Т а и Т с конкурентно. Контроллер В голосует за обе транзакции, т.к. он находится в начальном состоянии. А и С голосуют друг за друга после проверки, что транзакции Т а и Т с совместимы (б). Инициируется локальное выполнение транзакций (в) и после завершения локального выполнения сигнализируется окончание (г). Алгоритмы асинхронного голосования были использованы в распределённой базе данных SDD 1. В этой системе транзакции группируются в набор классов транзакций в соответствии сих наборами чтения и записи. Классы транзакций предварительно определяются администратором базы данных. С целью уменьшения затрат на синхронизацию разработаны четыре различных протокола синхронизации. Протокол Р1 предоставляет управление на нижнем уровне, обладая минимальной стоимостью и высокой эффективностью, в то время, как протокол Р4 обеспечивает верхний уровень управления, обладая большими накладными расходами. Протоколы выбираются в соответствии с классами транзакций. Упорядочивание запросов чтения/записи от различных параллельных транзакций осуществляется путём присваивания временных штампов транзакциям и записи этих временных штампов во все запрошенные элементы базы данных, к которым конкретная транзакция имеет доступ.Изменение копии элемента базы данных предоставляется транзакции только в том случае, если временной штамп запроса транзакции на изменение более новый по сравнению с временным штампом копии. Это гарантирует, что все копии приходят в одинаковое состояние одновременно с прекращением процедур их обновления. Класс транзакций в SDD 1 определён как набор транзакций, связанных с отдельной хост ЭВМ, на которой расположена новая база данных. Все транзакции, принадлежащие характеризуются взаимоисключающими наборами чтения

и взаимоисключающими наборами записи

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

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

. Примитивы и неделимы, в то время как комбинация L и U транзакции t не нуждаются в неделимости. В SDD 1 возможна такая последовательность примитивов L и U при условии, что история выполнения трёх транзакций t1,t2 и t3 сохраняется .Для определения возможного взаимовлияния транзакций из разных классов, вызванного перекрытием наборов записи и чтения, предлагается конструкция, названная L U графом. Этот граф соединяет пары узлов, отмеченных как L и U для каждого класса .Дуги между

и остальными узлами находятся в соответствии со следующими типами взаимовлияния транзакций: 1 .Дуга к узлу U, принадлежащему к тому же классу. 2 .Дуга к узлу

другого класса на той же хост ЭВМ m возникает при выполнении условий

или

(горизонтальная дуга). 3 .Дуга к узлу

того же класса, расположенному на другой хост ЭВМ возникает, если

(горизонтальная дуга). 4. Дуга к узлу U другого класса, расположенному на другой хост ЭВМ возникает, если

, . 5. Дуги между узлом U и другими узлами возникают по следующему правилу: к , если

и (диагональная дуга). На рис. 1.3. показан L U граф для транзакций классов

при условиях

Как только граф L U для данной системы построен, определяется таблица для выбора одного из четырёх протоколов Р1 Р4 для каждого класса транзакций в соответствии с топологией L U по следующим правилам. Протоколы Р2 и Р3 идентичны, за исключением правил присваивания временного штампа голосовательным сообщениям, которые широковещательно адресуются всем контроллерам. Протокол Р2 выбирает наиболее новый временной штамп из , в то время как Р3 выбирает временной штамп с текущим временем. На рис. 1.4. показана работа протоколов Р2 и Р3. Предположим, что две транзакции t a и t c конкурируют, причём транзакция t c имеет более новый временной штамп. Тогда контроллеры А,В и С взаимодействуют следующим образом при голосовании:

Если к А приходит голос за t c , он помещается в очередь.

МИНОБРНАУКИ РОССИИ

Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования

«Казанский национальный исследовательский технологический университет»

(ФГБОУ ВПО КНИТУ)

Институт управления, автоматизации и информационных технологий

Факультет управления и автоматизации

Кафедра «Автоматизированных систем сбора и обработки информации»

Реферат

Тема: Общая классификация и характеристика технологий распределенных информационных систем

Казань – 2015 год

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

1.1 Предпосылки создания информационных систем…..………………………..…3

1.2. Понятие распределенных информационных систем……………………………4

2. Информационные технологии в распределенных системах……………………..6

2.1. Система распределенной обработки данных……………………………………7

2.2. Технологии и модели «Клиент-Сервер»…………………………………………..9

2.3. Технологии объектного связывания данных……………………………………..13

2.4. Технологии реплицирования данных………………………………………………15

3. Средства работы с распределенными данными…………………………………..16

3.1. Распределенные базы данных……………………………………………………..17

3.2. Типы распределенных баз данных………………………………………………...20

3.3. Назначение и принципы работы распределенных баз данных……………….20

4. Примеры распределенных систем…………………………………………………..22

Библиографический список…………………………………………………………..25

ВВЕДЕНИЕ

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

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

В данной работе рассмотрены основные сведения о распределенной информационной системе: описаны предпосылки ее развития, средства работы с данными, введено понятие распределенной базы данных, а также ее типов и основных принципов. В третьей главе представлены примеры распределенных информационных систем, такие как: - Informix On-Line фирмы Informix Software;- Ingres Intelligent Database фирмы Ingres Corp;- Oracle (version 7) фирмы Oracle Corp;- Sybase System 10 фирмы Sybase Inc.

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

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

1. ПОНЯТИЕ РАСПРЕДЕЛЕННЫХ ИФОРМАЦИОННЫХ СИСТЕМ

1.1. Предпосылки создания распределенных ИС

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

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

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

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

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

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

1.2. Понятие распределенных информационных систем

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

средних и крупных распределенных систем.

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

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

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

Данные из разнородных систем обычно объединяются в логические группы, к которой и адресуются запросы. Абстрактная система запросов предполагает, что система оперирует не конкретным синтаксисом запросов, а его логической сутью на основе абстрактных атрибутов.
При построении распределенных ИС, как правило, используются две базовые архитектуры: Клиент/сервер и Internet Intranet .
Корпоративные ИС, построенные по архитектуре Клиент/сервер , предоставляют клиентам широкий спектр приложений и инструментов разработки, которые ориентированы на максимальное использование вычислительных возможностей клиентских рабочих мест. Ресурсы сервера используются в основном для хранения и обмена документами, а также для выхода во внешнюю среду. Данная архитектура позволяет лучше защитить серверную часть приложений, при этом, предоставляя возможность приложениям либо непосредственно адресоваться к другим серверным приложениям, либо маршрутизировать запросы к ним. Однако, частые обращения клиента к серверу снижают производительность работы сети. Приходится решать вопросы безопасной работы в сети, так как приложения и данные распределены между различными клиентами. Распределенный характер построения системы обусловливает сложность ее настройки и сопровождения

В основе ИС на базе Internet Intranet лежит принцип "открытой архитектуры". ПО ИС реализуется в виде аплетов или сервлетов (программ на языке JAVA) или в виде cgi модулей (программ на Perl или С). ИС данной архитектуры включает Web-yinh\, реализованные при помощи технологий CORBA Enterprise JavaBeans, ActiveX 1X"ОМ, многоуровневые приложения на основе Java и XML, .Net-концепция с XML, в которой обмен между различными серверами (хранилищами данных, бизнес-приложениями, серверами для мобильных клиентов и другое) производится при помощи нейтрального к любой архитектуре XML.

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

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

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

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

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

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

2. ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ В РАСПРЕДЕЛЕННЫХ СИСТЕМАХ

Технологии распределенных вычислений (РВ) Современное производство требует высоких скоростей обработки информации, удобных форм ее хранения и передачи. Необходимо также иметь динамичные способы обращения к информации, способы поиска данных в заданные временные интервалы, чтобы реализовывать сложную математическую и логическую обработку данных. Управление крупными предприятиями, управление экономикой на уровне страны требуют участия в этом процессе достаточно крупных коллективов. Такие коллективы могут располагаться в различных районах города, в различных регионах страны и даже в различных странах. Для решения задач управления, обеспечивающих реализацию экономической стратегии, становятся важными и актуальными скорость и удобство обмена информацией, а также возможность тесного взаимодействия всех участвующих в процессе выработки управленческих решений. В эпоху централизованного использования ЭВМ с пакетной обработкой информации пользователи вычислительной техники предпочитали приобретать компьютеры, на которых можно было бы решать почти все классы их задач. Однако сложность решаемых задач обратно пропорциональна их количеству, и это приводило к неэффективному использованию вычислительной мощности ЭВМ при значительных материальных затратах. Нельзя не учитывать и тот факт, что доступ к ресурсам компьютеров был затруднен из-за существующей политики централизации вычислительных средств в одном месте. Принцип централизованной обработки данных (рис. 5.1) не отвечал высоким требованиям к надежности процесса обработки, затруднял развитие систем и не мог обеспечить необходимые временные параметры при диалоговой обработке данных в многопользовательском режиме. Кратковременный выход из строя центральной ЭВМ приводил к роковым последствиям для системы в целом. I Рис. 5.1 - Система централизованной обработки данных Появление персональных компьютеров потребовало нового подхода к организации систем обработки данных, к созданию новых информационных технологий.

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

2.1. Система распределенной обработки данных .

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

Пример 1 . Три ЭВМ объединены в комплекс для распределения заданий, поступающих на обработку. Одна из них выполняет диспетчерскую функцию и распределяет задания в зависимости от занятости одной из двух других обрабатывающих ЭВМ. Это локальный многомашинный комплекс.

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

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

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

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

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

- технологии "Клиент-сервер",

- технологии реплицирования,

- технологии объектного связывания .

2.2. Технологии и модели «Клиент-сервер»

Технологии и модели "Клиент-сервер" Системы на основе технологий "Клиент-сервер" исторически выросли из первых централизованных многопользовательских автоматизированных информационных систем, интенсивно развивавшихся в 70-х годах (системы mainframe), и получили, вероятно, наиболее широкое распространение в сфере информационного обеспечения крупных предприятий и корпораций. В технологиях "Клиент-сервер" отступают от одного из главных принципов создания и функционирования распределенных систем - отсутствия центральной установки. Поэтому можно выделить две основные идеи, лежащие в основе клиент-серверных технологий: общие для всех пользователей данные на одном или нескольких серверах; много пользователей (клиентов), на различных вычислительных установках, совместно (параллельно и одновременно) обрабатывающих общие данные. Иначе говоря, системы, основанные на технологиях "Клиент-сервер", распределены только в отношении пользователей, поэтому часто их не относят к "настоящим" распределенным системам, а считают отдельным классом многопользовательских систем.

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

- модель файлового сервера (File Server - FS);

- модель удаленного доступа к данным (Remote Data Access - RDA);

- модель сервера базы данных (DataBase Server - DBS);

- модель сервера приложений (Application Server - AS).

Модель файлового сервера является наиболее простой и характеризует не столько способ образования информационной системы, сколько общий способ взаимодействия компьютеров в локальной сети. Один из компьютеров сети выделяется и определяется файловым сервером, т. е. общим хранилищем любых данных. В FS-модели все основные компоненты размещаются на клиентской установке. При обращении к данным ядро СУБД, в свою очередь, обращается с запросами на ввод-вывод данных за сервисом к файловой системе. С помощью функций операционной системы в оперативную память клиентской установки полностью или частично на время сеанса работы копируется файл базы данных. Таким образом, сервер в данном случае выполняет чисто пассивную функцию. Достоинством данной модели являются ее простота, отсутствие высоких требований к производительности сервера (главное, требуемый объем дискового пространства). Следует также отметить, что программные компоненты СУБД в данном случае не распределены, т.е. никакая часть СУБД на сервере не инсталлируется и не размещается. Недостатки данной модели - высокий сетевой трафик, достигающий пиковых значений особенно в момент массового вхождения в систему пользователей, например в начале рабочего дня. Однако более существенным недостатком, с точки зрения работы с общей базой данных, является отсутствие специальных механизмов безопасности файла (файлов) базы данных со стороны СУБД. Иначе говоря, разделение данных между пользователями (параллельная работа с одним файлом данных) осуществляется только средствами файловой системы ОС для одновременной работы нескольких прикладных программ с одним файлом.

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

Модель удаленного доступа к данным основана на учете специфики размещения и физического манипулирования данных во внешней памяти для реляционных СУБД. В RDA-модели компонент доступа к данным в СУБД полностью отделен от двух других компонентов (компонента представления и прикладного компонента) и размещается на сервере системы. Компонент доступа к данным реализуется в виде самостоятельной программной части СУБД, называемой SQL-сервером, и инсталлируется на вычислительной установке сервера системы. Функции SQL-сервера ограничиваются низкоуровневыми операциями по организации, размещению, хранению и манипулированию данными в дисковой памяти сервера. Иначе говоря, SQL-сервер играет роль машины данных. В файле (файлах) базы данных, размещаемом на сервере системы, находится также и системный каталог базы данных, в который помещаются в том числе и сведения о зарегистрированных клиентах, их полномочиях и т. п. На клиентских установках инсталлируются программные части СУБД, реализующие интерфейсные и прикладные функции. Пользователь, входя в клиентскую часть системы, регистрируется через нее на cepвере системы и начинает обработку данных. Прикладной компонент системы (библиотеки запросов, процедуры обработки данных) полностью размещается и выполняется на клиентской установке. При реализации своих функций прикладной компонент формирует необходимые SQL-инструкции, направляемые SQL-серверу. SQL-сервер, представляющий специальный программный компонент, ориентированный на интерпретацию SQL-инструкций и высокоскоростное выполнение низкоуровневых операций с данными, принимает и координирует SQL-инструкции от различных клиентов, выполняет их, проверяет и обеспечивает выполнение ограничений целостности данных и направляет клиентам результаты обработки SQL-инструкций, представляющие, как известно, наборы (таблицы) данных. Таким образом, общение клиента с сервером происходит через SQL-инструкции, а с сервера на клиентские установки передаются только результаты обработки, т. е. наборы данных, которые могут быть существенно меньше по объему всей базы данных. В результате резко уменьшается загрузка сети, а сервер приобретает активную центральную функцию. Кроме того, ядро СУБД в виде SQL-сервера обеспечивает также традиционные и важные функции по обеспечению ограничений целостности и безопасности данных при совместной работе нескольких пользователей. Другим, может быть неявным, достоинством RDA-модели является унификация интерфейса взаимодействия прикладных компонентов информационных систем с общими данными. Такое взаимодействие стандартизовано в рамках языка SQL специальным протоколом ODBC (Open Database Connectivity - открытый доступ к базам данных), играющим важную роль в обеспечении интероперабельности (многопротокольность), т.е. независимости от типа СУБД на клиентских установках в распределенных системах. Интероперабельность (многопротокольность) СУБД - способность СУБД обслуживать прикладные программы, первоначально ориентированные на разные типы СУБД. Иначе говоря, специальный компонент ядра СУБД на сервере (так называемый драйвер ODBC) способен воспринимать, обрабатывать запросы и направлять результаты их обработки на клиентские установки, функционирующие под управлением реляционных СУБД других, не "родных" типов. Такая возможность существенно повышает гибкость в создании распределенных информационных систем на базе интеграции уже существующих в какой-либо организации локальных баз данных под управлением настольных или другого типа реляционных СУБД. К недостаткам RDA-модели можно отнести высокие требования к клиентским вычислительным установкам, так как прикладные программы обработки данных, определяемые спецификой предметной области информационной системы, выполняются на них. Другим недостатком является все же существенный трафик сети, обусловленный тем, что с сервера базы данных клиентам направляются наборы (таблицы) данных, которые в определенных случаях могут занимать достаточно существенный объем.

Модель сервера базы данных (DBS-модель). Развитием PDA-модели стала модель сервера базы данных. Ее сердцевиной является механизм хранимых процедур. В отличие от RDA -модели, определенные для конкретной предметной области информационной системы события, правила и процедуры, описанные средствами языка SQL, хранятся вместе с данными на сервере системы и на нем же выполняются. Иначе говоря, прикладной компонент полностью размещается и выполняется на сервере системы. Модель сервера базы данных (DBS-модель) На клиентских установках в DBS-модели размещается только интерфейсный компонент (компонент представления), что существенно снижает требования к вычислительной установке клиента. Пользователь через интерфейс системы на клиентской установке направляет на сервер базы данных только лишь вызовы необходимых процедур, запросов и других функций по обработке данных. Все затратные операции по доступу и обработке данных выполняются на сервере и клиенту направляются лишь результаты обработки, а не наборы данных, как в RDA-модели. Этим обеспечивается существенное снижение трафика сети в DBS-модели по сравнению с RDA - моделью. Следует заметить, что на сервере системы выполняются процедуры прикладных задач одновременно всех пользователей системы. В результате резко возрастают требования к вычислительной установке сервера, причем как к объему дискового пространства и оперативной памяти, так и к быстродействию. Это основной недостаток DBS-модели. К достоинствам же DBS-модели , помимо разгрузки сети, относится и более активная роль сервера сети, размещение, хранение и выполнение на нем механизма событий, правил и процедур, возможность более адекватно и эффективно "настраивать" распределенную информационную систему на все нюансы предметной области. Также более надежно обеспечивается согласованность состояния и изменения данных и, вследствие этого, повышается надежность хранения и обработки данных, эффективно координируется коллективная работа пользователей с общими данными.

Модель сервера приложений (AS-модели). Чтобы разнести требования к вычислительным ресурсам сервера в отношении быстродействия и памяти по разным вычислительным установкам, используется модель сервера приложений. Суть AS-модели заключается в переносе прикладного компонента информационной системы на специализированный в отношении повышенных ресурсов по быстродействию дополнительный сервер системы. Как и в DBS-модели, на клиентских установках располагается только интерфейсная часть системы, т. е. компонент представления. Однако вызовы функций обработки данных направляются на сервер приложений, где эти функции совместно выполняются для всех пользователей системы. За выполнением низкоуровневых операций по доступу и изменению данных сервер приложений, как в RDA-модели, обращается к SQL-серверу, направляя ему вызовы SQL-процедур, и получая, соответственно, от него наборы данных. Как известно, последовательная совокупность операций над данными (SQL-инструкций), имеющая отдельное смысловое значение, называется транзакцией. В этом отношении сервер приложений управляет формированием транзакций, которые выполняет SQL-сервер. Поэтому программный компонент СУБД, инсталлируемый на сервере приложений, еще называют монитором обработки транзакций (Transaction Processing Monitors - TRM), или просто монитором транзакций. AS-модель, сохраняя сильные стороны DBS-модели, позволяет оптимально построить вычислительную схему информационной системы, однако, как и в случае RDA-модели, повышает трафик сети. В практических случаях используются смешанные модели, когда простейшие прикладные функции и обеспечение ограничений целостности данных поддерживаются хранимыми на сервере процедурами (DBS-модель), а более сложные функции предметной области (так называемые правила бизнеса) реализуются прикладными программами на клиентских установках (RDA-модель) или на сервере приложений (AS-модель).

2.3. Технологии объектного связывания данных .

Унификация взаимодействия прикладных компонентов с ядром информационных систем в виде SQL-серверов, наработанная для клиент-серверных систем, позволила выработать аналогичные решения и для интеграции разрозненных локальных баз данных под управлением настольных СУБД в сложные децентрализованные гетерогенные распределенные системы. Такой подход получил название объектного связывания данных. С узкой точки зрения, технология объектного связывания данных решает задачу обеспечения доступа из одной локальной базы, открытой одним пользователем, к данным в другой локальной базе (в другом файле), возможно находящейся на другой вычислительной установке, открытой и эксплуатируемой другим пользователем. Решение этой задачи основывается на поддержке современными "настольными" СУБД (MS Access, MS FoxPro, dBase и др.) технологии "объектов доступа к данным" - DАО .

При этом следует отметить, что под объектом понимается интеграция данных и методов, их обработки в одно целое (объект), на чем основываются объектно-ориентированное программирование и современные объектно-ориентированные операционные среды. Другими словами, СУБД, поддерживающие DАО, получают возможность внедрять и оперировать в локальных базах объектами доступа к данным, физически находящимся в других файлах, возможно на других вычислительных установках и под управлением других СУБД. Технически технология DАО основана на уже упоминавшемся протоколе ODBC, который принят за стандарт доступа не только к данным на SQL-серверах клиент-серверных систем, но и в качестве стандарта доступа к любым данным под управлением реляционных СУБД. Непосредственно для доступа к данным на основе протокола ODBC используются специальные программные компоненты, называемые драйверами ODBC (инициализируемые на тех установках, где находятся данные). Прежде всего, современные настольные СУБД обеспечивают возможность прямого доступа к объектам (таблицам, запросам, формам) внешних баз данных "своих" форматов. Иначе говоря, в открытую в текущем сеансе работы базу данных пользователь имеет возможность вставить специальные ссылки-объекты и оперировать с данными из другой (внешней, т. е. не открываемой специально в данном сеансе) базы данных. Объекты из внешней базы данных, вставленные в текущую базу данных, называются связанными и, как правило, имеют специальные обозначения для отличия от внутренних объектов. При этом следует подчеркнуть, что сами данные физически в файл (файлы) текущей базы данных не помещаются, а остаются в файлах своих баз данных. В системный каталог текущей базы данных помещаются все необходимые для доступа сведения о связанных объектах - внутреннее имя и внешнее, т. е. истинное имя объекта во внешней базе данных, полный путь к файлу внешней базы и г. п. Связанные объекты для пользователя ничем не отличаются от внутренних объектов. Пользователь может также открывать связанные во внешних базах таблицы данных, осуществлять поиск, изменение, удаление и добавление данных, строить запросы по таким таблицам и т. д. Связанные объекты можно интегрировать в схему внутренней базы данных, т е. устанавливать связи между внутренними и связанными таблицами. Технически оперирование связанными объектами из внешних баз данных "своего" формата мало отличается от оперирования с данными из текущей базы данных. Ядро СУБД при обращении к данным связанного объекта по системному каталогу текущей базы данных находит сведения о месте нахождения и других параметрах соответствующего файла (файлов) внешней базы данных и прозрачно (т. е. невидимо для пользователя) открывает этот файл (файлы). Далее обычным порядком организует в оперативной памяти буферизацию страниц внешнего файла данных для непосредственно доступа и манипулирования данными. Следует также заметить, что на основе возможностей многопользовательского режима работы с файлами данных современных операционных систем, с файлом внешней базы данных, если он находится на другой вычислительной установке, может в тот же момент времени работать и другой пользователь, что и обеспечивает коллективную обработку общих распределенных данных. Подобный принцип построения распределенных систем при больших объемах данных в связанных таблицах приведет к существенному увеличению трафика сети, так как по сети постоянно передаются даже не наборы данных, а страницы файлов баз данных, что может приводить к пиковым перегрузкам сети. Поэтому представленные схемы локальных баз данных со взаимными связанными объектами нуждаются в дальнейшей тщательной проработке. Не менее существенной проблемой является отсутствие надежных механизмов безопасности данных и обеспечения ограничений целостности. Совместная работа нескольких пользователей с одними и теми же данными обеспечивается только функциями операционной системы по одновременному доступу к файлу нескольких приложений. Аналогичным образом обеспечивается доступ к данным, находящимся в базах данных наиболее распространенных форматов других СУБД, таких, например, как базы данных СУБД FoxPro, dBASE. При этом доступ может обеспечиваться как непосредственно ядром СУБД, так и специальными дополнительными драйверами ISAM (Indexed Sequential Access Method), входящими, как правило, в состав комплекта СУБД. Объектное связывание ограничивается только непосредственно таблицами данных, исключая другие объекты базы данных (запросы, формы, отчеты), реализация и поддержка которых зависят от специфики конкретной СУБД. Определенной проблемой технологий объектного связывания является появление "брешей" в системах защиты данных и разграничения доступа. Вызовы драйверов ODBC для осуществления процедур доступа к данным помимо пути, имени файлов и требуемых объектов (таблиц), если соответствующие базы защищены, содержат в открытом виде пароли доступа, в результате чего может быть проанализирована и раскрыта система разграничения доступа и защиты данных.

2.4. Технологии реплицирования данных

Во многих случаях узким местом распределенных систем, построенных на основе технологий "Клиент-сервер" или объектного связывания данных, является недостаточно высокая производительность из-за необходимости передачи по сети большого количества данных. Определенную альтернативу построения быстродействующих распределенных систем предоставляют технологии реплицирования данных . Репликой называют особую копию базы данных для размещения на другом компьютере сети с целью автономной работы пользователей с одинаковыми (согласованными) данными общего пользования. Основная идея реплицирования заключается в том, что пользователи работают автономно с одинаковыми (общими) данными, растиражированными по локальным базам данных, обеспечивая с учетом отсутствия необходимости передачи и обмена данными по сети максимальную для своих вычислительных установок производительность. Тиражирование (или репликация,) - создание дублирующих копий (репликатов) объектов данных на разных узлах с целью повышения доступности и/или сокращения времени доступа к критически важным данным. Программное обеспечение СУБД для реализации такого подхода соответственно дополняется функциями тиражирования (реплицирования) баз данных, включая тиражирование как самих данных и их структуры, так и системного каталога с информацией о размещении реплик, иначе говоря, с информацией о конфигурировании построенной таким образом распределенной системы. При этом, однако, возникают две проблемы обеспечения одного из основополагающих принципов построения и функционирования распределенных систем (а именно, - непрерывности согласованного состояния данных): обеспечение согласованного состояния во всех репликах количества и значений общих данных; обеспечение согласованного состояния во всех репликах структуры данных. Обеспечение согласованного состояния общих данных, в свою очередь, основывается на реализации одного из двух принципов: принципа непрерывного размножения обновлений (любое обновление данных в любой реплике должно быть немедленно размножено); принципа отложенных обновлений (обновления реплик могут быть отложены до специальной команды или ситуации). Принцип непрерывного размножения обновлений является основополагающим при построении так называемых систем реального времени, таких, например, как системы управления воздушным движением, системы бронирования билетов пассажирского транспорта и т.п., где требуется непрерывное и точное соответствие реплик или других растиражированных данных во всех узлах и компонентах подобных распределенных систем. Реализация принципа непрерывного размножения обновлений заключается в том, что любая транзакция считается успешно завершенной, если она успешно завершена на всех репликах системы. На практике реализация этого принципа встречает существенные затруднения. В целом ряде предметных областей распределенных информационных систем режим реального времени с точки зрения непрерывности согласования данных не требуется. Такие системы автоматизируют те организационно-технологические структуры, в которых информационные процессы не столь динамичны. В этом случае обновление реплик распределенной информационной системы, если она будет построена на технологии реплицирования, требуется, скажем, только лишь один раз за каждый рабочий час, или за каждый рабочий день. Такого рода информационные системы строятся на основе принципа отложенных обновлений. Накопленные в какой-либо реплике изменения данных специальной командой пользователя направляются для обновления всех остальных реплик систем. Такая операция называется синхронизацией реплик. Решение второй проблемы согласованности данных, а именно -согласованности структуры данных, осуществляется через частичное отступление, как и в системах "Клиент-сервер", от принципа отсутствия центральной установки и основывается на технике главной реплики, т.е одна из реплик базы данных объявляется главной. При этом изменять структуру базы данных можно только в главной реплике. Эти изменения структуры данных тиражируются на основе принципа отложенных обновлений, т.е. через специальную синхронизацию реплик. Частичность отступления от принципа отсутствия центральной установки заключается в том, что в отличие от чисто централизованных систем, выход из строя главной реплики не влечет сразу гибель всей распределенной системы, так как остальные реплики продолжают функционировать автономно. Более того, на практике СУБД, поддерживающие технологию реплицирования, позволяют пользователю с определенными полномочиями (администратору системы) преобразовать любую реплику в главную и тем самым полностью восстановить работоспособность всей системы. Технологии репликации данных в тех случаях , когда не требуется обеспечивать большие потоки и интенсивность обновляемых в информационной сети данных, являются экономичным решением проблемы создания распределенных информационных систем с элементами централизации по сравнению с использованием дорогостоящих клиент-серверных систем.

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

3. СРЕДСТВА РАБОТЫ С РАСПРЕДЕЛЕННЫМИ ДАННЫМИ

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

1) Фрагментация и дублирование

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

2) Словари данных и директории

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

3) Двухфазная фиксация изменений

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

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

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

Таблица, содержащая информацию о детях сотрудников;

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

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

Все эти таблицы содержат столбец "ФИО сотрудника". Правила обеспечения ссылочной целостности требуют, чтобы при изменении значений столбца "ФИО сотрудника" в одной таблице, автоматически выполнялась корректировка значений этого столбца в других таблицах. Для обеспечения ссылочной целостности используются 2 различных метода - триггеры и декларативные ограничения целостности стандарта ANSI.

3.1. РАСПРЕДЕЛЕННЫЕ БАЗЫ ДАННЫХ

Основные принципы

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

РБД состоит из набора узлов, связанных коммуникационной сетью, в которой:

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

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

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

Фундаментальный принцип создания распределённых баз данных («правило 0»): Для пользователя распределённая система должна выглядеть так же, как нераспределённая система.

Фундаментальный принцип имеет следствием определённые дополнительные правила или цели. Таких целей всего двенадцать:

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

2.Отсутствие опоры на центральный узел. Локальная независимость предполагает, что все узлы в распределённой системе должны рассматриваться как равные. Поэтому не должно быть никаких обращений к «центральному» или «главному» узлу с целью получения некоторого централизованного сервиса.

3. Непрерывное функционирование. Распределённые системы должны предоставлять более высокую степень надёжности и доступности.

4. Независимость от расположения. Пользователи не должны знать, где именно данные хранятся физически и должны поступать так, как если бы все данные хранились на их собственном локальном узле.

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

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

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

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

8.Управление распределёнными транзакциями.

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

9.Аппаратная независимость .

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

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

Возможность функционирования СУБД под различными операционными системами.

11.Независимость от сети.

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

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

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

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

3.2. Типы распределенных БД

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

Помимо вышеназванных типов распределенных баз данных можно выделить следующие:

1) Распределённые Базы Данных

2) Мультибазы данных с глобальной схемой. Система Мультибаз данных - это распределённая система, которая служит внешним интерфейсом для доступа ко множеству локальных СУБД или структурируется, как глобальный уровень над локальными СУБД.

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

4) Мультибазы с общим языком доступа - распределённые среды управления с технологией "клиент-сервер"

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

3.3. Назначение и принцип работы распределенной БД

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

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

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

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

Рис.1.

Принцип работы БД

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

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

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

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

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

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

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

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

1) В базе-источнике система определяет список изменённых объектов за время, прошедшее с предыдущего сеанса выгрузки данных.

2) По данному списку система формирует XML-пакет, который передается в базу-приемник.

Для того чтобы сформировать пакет система обращается к измененным объектам базы данных. При обращении система блокирует данные объекты.

3) XML-пакет передается в базу-приемник.

В базе-приемнике XML-пакет разворачивается и изменения, содержащиеся в нем, вносятся в базу.

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

4. ПРИМЕРЫ РАСПРЕДЕЛЕННЫХ СИСТЕМ

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

Среди многочисленных прототипов и научно-исследовательских систем следует упомянуть систему SDD-1 , созданную в конце 70-х -- начале 80-х годов в научно-исследовательском отделении фирмы Computer Corporation of America; систему R* , которая является распределенной версией системы System R и создана в начале 80-х годов фирмой IBM; а также систему Distributed INGRES , которая является распределенной версией системы INGRES и создана также в начале 80-х годов в Калифорнийском университете в Беркли.

Что касается коммерческих продуктов, то в настоящее время в большинстве реляционных систем предусмотрены разные виды поддержки использования распределенных баз данных с разной степенью функциональности. Среди таких систем наиболее известны система INGRES/STAR отделения Ingres Division фирмы The ASK Group Inc., система ORACLE фирмы Oracle Corporation, а также модуль распределенной работы системы DB2 фирмы IBM.

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

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

- Informix On-Line фирмы Informix Software;

- Ingres Intelligent Database фирмы Ingres Corp;

- Oracle (version 7) фирмы Oracle Corp;

- Sybase System 10 фирмы Sybase Inc.

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

Наиболее полно функции распределенной СУБД реализованы в СУБД Ingres и Oracle . Коротко рассмотрим возможности этих пакетов.

СУБД Ingres работает на множестве UNIX-платформ, на платформах DEC VMS, Hewlett-Packard MPE, DOS, Microsoft Windows 3.1, OS/2, Macintosh. Она также работает со многими сетевыми протоколами, включая Open System Interconnection Transport Class 4. Ingres имеет средства для доступа к данным СУБД DB2, Rdb, Allbase. Основные функции распределенной СУБД обеспечиваются дополнительной компонентой Ingres/Star. Она поддерживает оптимизацию распределенных запросов, позволяет читать и обновлять в рамках одной транзакции данные разных узлов, обеспечивает возможность удалять записи одновременно в нескольких узлах.

СУБД Informix-Online разработана для среды UNIX, но может также работать под Novell. Informix-Online имеет оптимизатор запросов и реализует те же функции работы с распределенной БД, что и Ingres, однако у Informix более жесткие требования к ресурсам компьютера, в частности ему требуется больше оперативной памяти.

СУБД System 10 фирмы Sybase в настоящее время находится в состоянии разработки. Она должна работать на UNIX-платформах, на платформах OS/2, Window NT, NetWare. System 10 будет работать с несколькими сетевыми протоколами и поддерживать связь с СУБД DB2, Oracle 7, Informix-Online, Rdb. System 10 будет иметь оптимизатор распределенных запросов, она позволит читать и обновлять данные нескольких узлов. Функции работы с распределенной БД будут реализованы с помощью дополнительной компоненты Replication Server.

В 7 версии СУБД Oracle реализовано множество функций для работы с распределенной БД. Среди них следует выделить оптимизатор распределенных запросов и средство чтения и обновления данных нескольких узлов в рамках одной транзакции. Oracle v 7 работает на более чем 80 вычислительных платформах, поддерживает большинство существующих коммерческих сетевых протоколов и может обмениваться данными с СУБД DB2, SQL/DS, Tandem Computers, NonStop SQL, Rdb, HP TurboImage. Разрабатываются шлюзы еще к 18 СУБД.

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

Все 4 рассмотренные СУБД поддерживают локальную автономию узлов . Это означает, что администратор БД может рассматривать локальную БД конкретного узла как самостоятельную БД. Все СУБД поддерживают ANSI стандарт языка SQL - ANSI SQL-89 и расширение этого стандарта. Запросы к БД формулируются на языке SQL. Дополнительно к непроцедурному языку SQL Oracle поддерживает свой собственный процедурный язык PL/SQL, а Sybase поддерживает свой язык Transact-SQL.

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

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

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

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

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

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

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

Библиографический список

1. Распределенные базы данных. Википедия.

8. Коннолли, Т., Бегг, К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика. 3-е издание.: Пер. с англ. - М.: Издательский дом «Вильяме», 2003. – 433 с.

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

РБД состоит из набора узлов, связанных коммуникационной сетью, в которой:

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

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

Фундаментальный принцип создания распределённых баз данных («правило 0»): Для пользователя распределённая система должна выглядеть так же, как нераспределённая система.

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

Отсутствие опоры на центральный узел. Локальная независимость предполагает, что все узлы в распределённой системе должны рассматриваться как равные. Поэтому не должно быть никаких обращений к «центральному» или «главному» узлу с целью получения некоторого централизованного сервиса.

Непрерывное функционирование. Распределённые системы должны предоставлять более высокую степень надёжности и доступности.

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

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

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

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

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

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

Независимость от операционной системы. Возможность функционирования СУБД под различными операционными системами.

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

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

Типы распределённых баз данных

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

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

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

Мультибазы с общим языком доступа - распределённые среды управления с технологией «клиент-сервер»

ВВЕДЕНИЕ 4

1.ПОНЯТИЕ РАСПРЕДЕЛЕННЫХ ИС 6

1.1. Предпосылки создания распределенных ИС 6

1.2. Понятие распределенных информационных систем 8

1.3. Средства работы с распределенными данными 11

2. РАСПРЕДЕЛЕННЫЕ БАЗЫ ДАННЫХ 13

2.1. Основные принципы 13

2.2 Типы распределенных БД 15

2.3. Назначение и принцип работы распределенной БД 16

3. ПРИМЕРЫ РАСПРЕДЕЛЕННЫХ СИСТЕМ 21

ЗАКЛЮЧЕНИЕ 25

ЛИТЕРАТУРА 26

ВВЕДЕНИЕ

1.ПОНЯТИЕ РАСПРЕДЕЛЕННЫХ ИС

1.1. Предпосылки создания распределенных ИС

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

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

1.2. Понятие распределенных информационных систем

Данные из разнородных систем обычно объединяются в логические группы, к которой и адресуются запросы. Абстрактная система запросов предполагает, что система оперирует не конкретным синтаксисом запросов, а его логической сутью на основе абстрактных атрибутов.
При построении распределенных ИС, как правило, используются две базовые архитектуры: Клиент/сервер и Internet Intranet.
Корпоративные ИС, построенные по архитектуре Клиент/сервер, предоставляют клиентам широкий спектр приложений и инструментов разработки, которые ориентированы на максимальное использование вычислительных возможностей клиентских рабочих мест. Ресурсы сервера используются в основном для хранения и обмена документами, а также для выхода во внешнюю среду. Данная архитектура позволяет лучше защитить серверную часть приложений, при этом, предоставляя возможность приложениям либо непосредственно адресоваться к другим серверным приложениям, либо маршрутизировать запросы к ним. Однако, частые обращения клиента к серверу снижают производительность работы сети. Приходится решать вопросы безопасной работы в сети, так как приложения и данные распределены между различными клиентами. Распределенный характер построения системы обусловливает сложность ее настройки и сопровождения

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

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

1.3. Средства работы с распределенными данными

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

1) Фрагментация и дублирование

2) Словари данных и директории

3) Двухфазная фиксация изменений

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

Таблица, содержащая информацию о детях сотрудников;

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

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

2. РАСПРЕДЕЛЕННЫЕ БАЗЫ ДАННЫХ

2.1. Основные принципы

РБД состоит из набора узлов, связанных коммуникационной сетью, в которой:

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

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

2.Отсутствие опоры на центральный узел. Локальная независимость предполагает, что все узлы в распределённой системе должны рассматриваться как равные. Поэтому не должно быть никаких обращений к «центральному» или «главному» узлу с целью получения некоторого централизованного сервиса.

3.Непрерывное функционирование. Распределённые системы должны предоставлять более высокую степень надёжности и доступности.

4.Независимость от расположения. Пользователи не должны знать, где именно данные хранятся физически и должны поступать так, как если бы все данные хранились на их собственном локальном узле.

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

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

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

9.Аппаратная независимость. Желательно иметь возможность запускать одну и ту же СУБД на различных аппаратных платформах и, более того, добиться, чтобы различные машины участвовали в работе распределённой системы как равноправные партнёры.

10.Независимость от операционной системы. Возможность функционирования СУБД под различными операционными системами.

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

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

2.2. Типы распределенных БД

Помимо вышеназванных типов распределенных баз данных можно выделить следующие:

1) Распределённые Базы Данных

4) Мультибазы с общим языком доступа - распределённые среды управления с технологией "клиент-сервер"

2.3. Назначение и принцип работы распределенной БД

Рис.2.1. Принцип работы БД

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

1)В базе-источнике система определяет список изменённых объектов за время, прошедшее с предыдущего сеанса выгрузки данных.

2)По данному списку система формирует XML-пакет, который передается в базу-приемник.

3) XML-пакет передается в базу-приемник.

В базе-приемнике XML-пакет разворачивается и изменения, содержащиеся в нем, вносятся в базу.

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

3. ПРИМЕРЫ РАСПРЕДЕЛЕННЫХ СИСТЕМ

Среди многочисленных прототипов и научно-исследовательских систем следует упомянуть систему SDD-1 , созданную в конце 70-х -- начале 80-х годов в научно-исследовательском отделении фирмы Computer Corporation of America; систему R* , которая является распределенной версией системы System R и создана в начале 80-х годов фирмой IBM; а также систему Distributed INGRES , которая является распределенной версией системы INGRES и создана также в начале 80-х годов в Калифорнийском университете в Беркли.

Что касается коммерческих продуктов, то в настоящее время в большинстве реляционных систем предусмотрены разные виды поддержки использования распределенных баз данных с разной степенью функциональности. Среди таких систем наиболее известны система INGRES/STAR отделения Ingres Division фирмы The ASK Group Inc., система ORACLE фирмы Oracle Corporation, а также модуль распределенной работы системы DB2 фирмы IBM.

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

Informix On-Line фирмы Informix Software;

Ingres Intelligent Database фирмы Ingres Corp;

Oracle (version 7) фирмы Oracle Corp;

Sybase System 10 фирмы Sybase Inc.

Наиболее полно функции распределенной СУБД реализованы в СУБД Ingres и Oracle. Коротко рассмотрим возможности этих пакетов.

СУБД Ingres работает на множестве UNIX-платформ, на платформах DEC VMS, Hewlett-Packard MPE, DOS, Microsoft Windows 3.1, OS/2, Macintosh. Она также работает со многими сетевыми протоколами, включая Open System Interconnection Transport Class 4. Ingres имеет средства для доступа к данным СУБД DB2, Rdb, Allbase. Основные функции распределенной СУБД обеспечиваются дополнительной компонентой Ingres/Star. Она поддерживает оптимизацию распределенных запросов, позволяет читать и обновлять в рамках одной транзакции данные разных узлов, обеспечивает возможность удалять записи одновременно в нескольких узлах.

СУБД Informix-Online разработана для среды UNIX, но может также работать под Novell. Informix-Online имеет оптимизатор запросов и реализует те же функции работы с распределенной БД, что и Ingres, однако у Informix более жесткие требования к ресурсам компьютера, в частности ему требуется больше оперативной памяти.

СУБД System 10 фирмы Sybase в настоящее время находится в состоянии разработки. Она должна работать на UNIX-платформах, на платформах OS/2, Window NT, NetWare. System 10 будет работать с несколькими сетевыми протоколами и поддерживать связь с СУБД DB2, Oracle 7, Informix-Online, Rdb. System 10 будет иметь оптимизатор распределенных запросов, она позволит читать и обновлять данные нескольких узлов. Функции работы с распределенной БД будут реализованы с помощью дополнительной компоненты Replication Server.

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

Все 4 рассмотренные СУБД поддерживают локальную автономию узлов. Это означает, что администратор БД может рассматривать локальную БД конкретного узла как самостоятельную БД. Все СУБД поддерживают ANSI стандарт языка SQL - ANSI SQL-89 и расширение этого стандарта. Запросы к БД формулируются на языке SQL. Дополнительно к непроцедурному языку SQL Oracle поддерживает свой собственный процедурный язык PL/SQL, а Sybase поддерживает свой язык Transact-SQL.

ЗАКЛЮЧЕНИЕ

ЛИТЕРАТУРА

1. Как организовать распределенную информационную базу?

http://www.intelis-it.ru/services/automation_act/information-systems.html

2. Распределенные базы данных. Википедия.

http://ru.wikipedia.org/wiki/распереленные_бд

3. Бойко В.В., Савинков В.М. Проектирование баз данных информационных систем. – 2-е изд. – М.: Финансы и статистика, 1989. – 350 с.

4. Дейт К. Дж. Введение в системы баз данных.: Пер. с англ. – 6-е изд. – Киев: Диалектика, 1998. – 784 с.

5. Распределенные информационные системы и базы данных. Глеб Ладыженский

http://articles.org.ru/cfaq/index.php?qid=1306&catid=54

6. . Глобально распределенные информационные системы

http://www.ci.ru/inform4_97/astr1.htm

7. Проектирование структуры распределенной базы данных.

http://www.integro.ru/projects/gis/quest_1.htm

http://www.lcard.ru/~nail/database/osbd/glava_~3.htm

10. Технологии распределенных баз данных

http://rema.44.ru//resurs/study/dblab/dblab.html.

Распределенная ИС

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

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

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

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

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

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

Впервые задача об исследовании основ и принципов создания и функционирования распределенных информационных систем была поставлена известным специалистом в области баз данных К. Дейтом в рамках уже не раз упоминавшегося (где он уже упоминался? ) проекта System R, что в конце 70-х - начале 80-х годов вылилось в отдельный проект создания первой распределенной системы (проект System R*). Большую роль в исследовании принципов создания и функционирования распределенных баз данных внесли также и разработчики системы Ingres.

Собственно в основе распределенных АИС лежат две основные идеи:

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

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

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

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

Изолированность пользователей друг от друга (пользователь должен «не чувствовать», «не видеть» работу других пользователей в тот момент, когда он изменяет, обновляет, удаляет данные);

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

Из основных вытекает ряд дополнительных принципов:

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

Отсутствие центральной установки (следствие предыдущего пункта);

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

Непрерывность функционирования (отсутствие плановых отключений системы в целом, например для подключения новой установки или обновления версии СУБД);

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

Независимость от реплицирования (дублирования) данных (когда какая-либо таблица базы данных, или ее часть физически может быть представлена несколькими копиями, расположенными на различных установках, причем «прозрачно» для пользователя);

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

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

Независимость от аппаратуры (желательно, чтобы система могла функционировать на установках, включающих компьютеры разных типов);

Независимость от типа операционной системы (система должна функционировать вне зависимости от возможного различия ОС на различных вычислительных установках);

Независимость от коммуникационной сети (возможность функционирования в разных коммуникационных средах);

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

В обиходе СУБД, на основе которых создаются распределенные информационные системы, также характеризуют термином «Распределенные СУБД», и, соответственно, используют термин «Распределенные базы данных» .

Важнейшую роль в технологии создания и функционирования распределенных баз данных играет техника «представлений» (Views).

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

Схематично идея техники представлений проиллюстрирована на рисунке.

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

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

CREA ТЕ VIEW ИмяПредставленият AS

SELECT...

FROM...

...;

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

Авторизация представлений осуществляется применением команд (директив) GRANT, присутствующих в базовом перечне инструкций языка SQL (см. п. 4.1) и предоставляющих полномочия и привилегии пользователям:

GRANT SELECTON ИмяПредставления TO ИмяПользователя1, ИмяПользователя2,...;

Соответственно директива REVOKE отменяет уставленные ранее привилегии.

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

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

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

Архитектура "файл-сервер"

С появлением сетей данные стали хранить на файл-сервере. Это первый вид многопользовательской системы. В этом случае их поиск и обработка происходит на рабочих станциях. При таком подходе на рабочую станцию посылаются не только данные, необходимые конечному пользователю, но и данные, которые используются только для выполнения запроса (например, фрагменты индексных файлов или данные, которые будут отброшены при выполнении запроса). Таким образом, объём “лишней” информации зачастую превышает объём “нужной”.

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

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

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

Практической опорой системных и прикладных программных средств открытых систем является стандартизованная операционная система. В настоящее время такой системой является UNIX. Фирмам-поставщикам различных вариантов ОС UNIX в результате длительной работы удалось прийти к соглашению об основных стандартах этой операционной системы. Сейчас все распространенные версии UNIX в основном совместимы по части интерфейсов, предоставляемых прикладным, а в большинстве случаев и системным программистам. По мнению многих специалистов, несмотря на появление претендующей на стандарт системы Windows NT, возможно именно UNIX останется основой открытых систем в ближайшие годы .

Технологии и стандарты открытых систем обеспечивают реальную и проверенную практикой возможность производства системных и прикладных программных средств со свойствами мобильности (portability) и интероперабельности (interoperability). Свойство мобильности означает сравнительную простоту переноса программной системы в широком спектре аппаратно-программных средств, соответствующих стандартам. Интероперабельность означает упрощения комплексирования новых программных систем на основе использования готовых компонентов со стандартными интерфейсами.

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

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

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

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

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

Объем оперативной памяти (далеко не все категории пользователей нуждаются в наличии большой оперативной памяти);

Наличие и объем дисковой памяти (достаточно популярны бездисковые рабочие станции, использующие внешнюю память дискового сервера);

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

Для третьих обязательно требуются мощные средства для работы с графикой и т.д.).

При необходимости можно использовать ресурсы и/или услуги (сервисы), предоставляемые сервером.

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

Примерами серверов могут служить:

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

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

Архитектура "клиент-сервер"

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

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

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

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

Приложения, написанные пользователями. Это в основном профессиональные прикладные программы, написанные либо на общепринятом языке программирования, таком как С или PASCAL, либо на некоторых оригинальных языках, таких как FOCUS, хотя в обоих случаях эти языки должны как-то связываться с соответствующим подъязыком данных.
Приложения, предоставляемые поставщиками (часто называемые инструментальными средствами). В целом назначение таких средств - содействовать в процессе создания и выполнения других приложений, т.е. приложений, которые делаются специально для некоторой специфической задачи (хотя созданные приложения могут и не выглядеть как приложения в общепринятом смысле). Действительно, эта категория инструментальных средств позволяет пользователям, особенно конечным, создавать приложения без написания традиционных программ. Например, одно из предоставляемых поставщиками инструментальных средств может быть процессором языка запросов, с помощью которого конечный пользователь может выдавать незапланированные запросы к системе. Каждый такой запрос является, по существу, не чем иным, как специальным приложением (например, ISQL СУБД MS SQL Server), предназначенным для выполнения некоторых специфических функций.

Поставляемые инструментальные средства, в свою очередь, делятся на несколько самостоятельных классов:

процессоры языков запросов;
генераторы отчетов;
графические бизнес-подсистемы;
электронные таблицы:
процессоры обычных языков;
средства управления копированием;
генераторы приложений;
другие средства разработки приложений, включая CASE-продукты (CASE или Computer-Aided Software Engineering - автоматизация разработки программного обеспечения), и т.д.

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

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

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

Архитектура клиент/сервер характеризуется наличием одной СУБД для всех пользователей, которая расположена на сервере. При

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

Однако время реакции в такой системе складывается из времени передачи запроса, времени ожидания ресурсов на сервере (например, процессора или дисковой операции), времени выполнения запроса и времени передачи результатов на рабочую станцию - программе-клиенту. Причём время ожидания на сервере может съедать львиную долю общего времени выполнения запроса. При разработке программ, работающих по технологии клиент-сервер, необходимо учитывать это и не обращаться к серверу за одной записью, а читать данные “пачками”.

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

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

Двухуровневая модель архитектуры клиент/сервер

Трехуровневая модель архитектуры клиент/сервер

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

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

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

Структура системы БД с выделением клиентов и сервера

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

Клиенты - это различные приложения, которые выполняются над СУБД.

Обычно в приложении выделяются следующие группы функций:

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

Двухуровневая модель архитектуры клиент/сервер

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

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

Модель файлового сервера

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

Помимо этого недостатка использование файлового сервера несет еще и другие:

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

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

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

Клиент обращается к серверу с запросами на языке SQL. Структура модели удаленного доступа приведена на рисунке.

Модель удаленного доступа

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

Тем не менее, данная технология обладает и рядом недостатков:

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

Технологию "клиент - сервер" поддерживают большинство современных СУБД: Informix, Ingres, Sybase, Oracle, MS SQL Server. В основу данной модели добавлен механизм хранимых процедур и механизм триггеров.

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

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

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

Триггер - это особый тип хранимой процедуры, реагирующий на возникновение определенного события в БД. Он активизируется при попытке изменения данных - при операциях добавления, обновления и удаления. Триггеры определяются для конкретных таблиц БД.

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

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

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

Модель сервера БД

Зачем все эти номера???

Трехуровневая модель архитектуры клиент/сервер

Трехуровневая модель является расширением двухуровневой модели и в ней вводится дополнительный промежуточный уровень между клиентом и сервером. Архитектура трехуровневой модели приведена на рисунке.

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

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

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

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

Принципы построения распределенных баз данных

Основные понятия

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

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

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

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

1. Имеется набор логически связанных разделяемых данных.

2. Сохраняемые данные разбиты на некоторое количество фрагментов.

3. Может быть предусмотрена репликация фрагментов данных.

4. Фрагменты и их копии распределяются по разным узлам.

5. Узлы связаны между собой сетевыми соединениями.

6. Доступ к данным на каждом узле происходит под управлением СУБД.

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

8. СУБД каждого узла поддерживает хотя бы одно глобальное приложение.

Что такое УЗЕ на этом рисунке??

Компьютерная

Рис. 2.1. – Топология распределенной СУБД

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

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

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

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

Преимущества и недостатки распределенных СУБД

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

Преимущества

Отражение структуры организации.

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

Высокая степень разделяемости и локальной автономности.

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

Повышение доступности данных.

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

Повышение надежности.

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

Повышение производительности.

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

Экономические выгоды.

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

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

Модульность системы.

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

Недостатки

Повышение сложности.

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

Увеличение стоимости.

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

Проблемы защиты.

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

Усложнение контроля за целостностью данных.

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

Отсутствие стандартов.

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

Недостаток опыта.

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

Усложнение процедуры разработки базы данных.

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

Однородные и разнородные распределенные СУБД

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

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

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

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

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

Обеспечение прозрачности в распределенной СУБД

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

1. Прозрачность размещения.

2. Прозрачность транзакций.

3. Прозрачность выполнения.

4. Прозрачность использования СУБД.

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

Прозрачность размещения

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

Прозрачность фрагментации.

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

Прозрачность местонахождения.

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

Прозрачность репликации.

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

Прозрачность локального отображения.

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

Прозрачность именования.

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

1. Утрата определенной части локальной автономии.

2. Появление проблем с производительностью (поскольку центральный узел превращается в узкое место всей системы).

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

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

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

Прозрачность транзакций

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

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

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

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

1. К какому фрагменту следует обратиться.

2. Какую копию фрагмента использовать, если его данные участвуют в репликации.

3. В какое место хранения данных следует обратиться.

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

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

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

3. Время, необходимое для передачи данных по сетевым соединениям.

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

Прозрачность использования СУБД

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

Двенадцать правил Дейта

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

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

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

1. Локальные данные принадлежат локальным владельцам и сопровождаются локально.

2. Все локальные операции остаются сугубо локальными.

3. Все операции на заданном узле контролируются только этим узлом.

Правило 2. Отсутствие зависимости от центрального узла.

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

Правило 3. Непрерывное функционирование.

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

1. Добавление и удаление узла из системы.

2. Динамическое создание и удаление фрагментов из одного или нескольких узлов.

Правило 4. Независимость от местонахождения.

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

Правило 5. Независимость от фрагментации.

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

Правило 6. Независимость от репликации.

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

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

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

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

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

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

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

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

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

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

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

Правило 12. Независимость от базы данных.

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

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

Возможности СУБД Oracle для построения распределенных баз данных

Распределенная СУБД Oracle

Корпорация Oracle первой ввела распределенные базы данных еще в начале 1980-х в ответ на требования организовать доступ к данным на разных платформах.

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

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

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

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

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

Р
Database link

identified by…

Database

EMP
DEP
Insert into EMP@SALES … ;

delete from DEP … ;

select … from EMP@SALES … ;

Приложение

установления как приватных, так и общедоступных связей.

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

Рис. 3.1 – Схема работы database link

Что такое СЕРВЕ на этом рисунке??

Связь базы данных задает следующую информацию:

1. Сетевой протокол (например, TCP/IP), который используется для соединения.

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

3. Имя базы данных на удаленном хосте.

4. Наименование учетной записи для доступа к удаленной базе данных.

5. Пароль к этой учетной записи.

Локальная БД

Удаленная

Рис. 3.2. – Схема подключения к удаленной БД

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

create database link

connect to {current_user | identified by
}

using "(DESCRIPTION =

Печать

Также интересно:

Dark Sector: Прохождение Глава VIII: Неестественная история

Что делать если на компе нету диска D?

Как откатить или удалить проблемное обновление Windows Откат к предыдущей сборке windows 10

Рекомендуем почитать:

2023-08-11 00:02:15

Оператор для работы с наборами UNION Объединение запросов union

2023-08-11 00:02:15

IBM создала самый мощный в мире компьютер Топ 10 самых мощных компьютеров в мире

2023-08-10 00:03:18

Мы знаем далеко не все: какие социальные сети существуют в интернете Путешествия и отдых

В продолжение темы:

Windows

Компьютеры с процессором intel i5 Конфигурация тестовых стендов

Часть вторая : "Важнейшие характеристики каждого семейства процессоров Intel Core i3/i5/i7. Какие из этих чипов представляют особый интерес" Введение Сначала мы приведём...

Новые статьи