Департамент образованияи науки Краснодарского края
Частноеобразовательное учреждение
среднегопрофессионального образования
«Колледж права,экономики и управления»-ЧОУ СПО «КПЭУ»
КУРСОВАЯ РАБОТА
по дисциплине: «Разработкаи эксплуатация удаленных баз данных»
МЕХАНИЗМЫРЕПЛИКАЦИЙ В РАСПРЕДЕЛЕННЫХ БАЗАХ
Краснодар 2010
СОДЕРЖАНИЕ
ВВЕДЕНИЕ
1. ТЕРМИНОЛОГИЯ, КЛАССИФИКАЦИЯ, КОНФЛИКТЫ
2. ОСНОВНЫЕ ВЫГОДЫВНЕДРЕНИЯ МЕХАНИЗМА РЕПЛИКАЦИЙ
2.1 О репликации базы данных
2.2 Механизмырепликации данных
2.3 Назначение репликации данных
2.4 Функциональныетребования к серверу репликации
2.5 Синхронная репликация
2.6 Асинхроннаярепликация
2.7 Основные принципы, правила построения ифункционирования РБД
ЗАКЛЮЧЕНИЕ
СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ
ВВЕДЕНИЕ
Проблема репликации(синхронизации данных) по нескольким источникам информации представляет собой довольнонетривиальную задачу с весьма неоднозначным решением. Как это ни странно,учитывая, что подобные проблемы возникают довольно часто, но универсальногорешения такой задачи на текущий момент практически нет. Почти все готовыерепликаторы данных работают с существенными ограничениями по структуре испособам накопления и изменения данных в таблицах базы данных.
Приступая к решениюболее или менее нетривиальной задачи о репликации данных, стоит быть готовым ктому, что порой приходиться натыкаться на неразрешимые конфликты реплицируемыхданных, каковых для баз данных, работающих в единой сети прямого коннекта ксерверу базы данных, не возникает в принципе. Особенно сложен переход от единойбазы к распределенной, когда приходиться подстраивать алгоритм репликации подуже существующую структуру работающей БД. Напротив, при разработке и написанияпроекта БД с нуля, всегда проще учесть технологические нюансы будущей распределеннойбазы.
1. ТЕРМИНОЛОГИЯ,КЛАССИФИКАЦИЯ, КОНФЛИКТЫ
Репликация(синхронизация) — процесс приведения данных электронныхтаблиц двух БД в идентичное состояние
Репликацию можноклассифицировать по разному.
1) Понаправлению репликации. Если данные изменяются только в однойиз БД, а в другой данные только хранятся и не подвергаются изменениям, то такуюрепликацию будем называть однонаправленной или односторонней. Если же данныемогут изменяться и вводиться на всех БД, то такой вид репликации будем называтьмультинаправленной или многосторонней.
2) Повремени проведения сеанса репликации. Если данные должныбыть засинхронизированны немедленно после изменений, то такую репликацию будемназывать репликация реального времени. Если же процесс репликации запускается,по какому-либо событию во времени или по отмашке администратора БД, то такойвид репликации назовем отложенная репликация.
3) Поспособу передачи информации во время процесса репликации.Если соединение серверов, хранящих распределенные БД, происходит при помощипрограммы клиента, которая с одной стороны коннектится к своему серверу, а сдругого конца имеет прямую связь с БД другого сервера и может подключитьсянапрямую к данным другого сервера, для прямого изменения и анализареплицируемых данных с обеих концов, имея при этом гарантированный устойчивыйканал связи (ADSL, выделенный канал, двухпроводная линия Dial-Up и пр.), тотакой вид синхронизации назовем прямым. Если же канал неустойчивый и негарантирует устойчивую связь без падений во время процесса синхронизации иданные приходится передавать цельными пачками, при этом принимающая сторона вовремя закачки и анализа данных не имеет немедленной возможности опроситьисточник при возникновении на ее взгляд сомнительных моментов, а решение«Что делать?» принимать в любом случае нужно, то такой видсинхронизации будем называть недетерминированной или вероятностной.
4) Поспособу анализа реплицируемой информации. Если ядро алгоритмаработает по принципу сравнения записей одной таблицы с записями другой, и наосновании этого принимается решение о синхронизации, то такой процесс будемназывать репликацией по текущему состоянию. Если в базе предусмотрен журналвносимых изменений в БД, и алгоритм репликации переносит изменения по дельтамизменений накопленным в журнале, то такой процесс назовем дельта репликацией.
Как видно из вышеприведенного списка,вариантов репликации существует довольно большое количество.
2. ОСНОВНЫЕВЫГОДЫ ВНЕДРЕНИЯ МЕХАНИЗМА РЕПЛИКАЦИЙ
1. Надежность — процесс репликации значительноувеличивает надежность системы, предоставляя приложениям альтернативный доступк данным. При потере соединения с одним из серверов, пользователь можетпродолжать работу с данными, используя другой.
2. Производительность — используя репликацию, можно обеспечить высокуюскорость доступа к данным, так как нагрузка будет равномерно распределена междумножеством баз репликации.
3. Возможностьработы баз с базой — локальная информационная базапозволяет пользователю работать с набором данных без наличия постоянногосоединения с базой данных. Позже, когда установится соединение, пользовательсможет синхронизировать (обновить) объекты, если это необходимо. И внесенные имизменения попадут в базу данных.
4. Уменьшениесетевой нагрузки — репликация может быть использованадля распределения данных между различными региональными центрами. Приложениябудут обращаться не к центральному серверу, а к региональному, тем самымуменьшая нагрузку на сеть.
5. Работа всехподписчиков с общими ресурсами — репликацияпозволяет каждому из подписчиков работать с общими ресурсами, например регистростатков или регистр бухгалтерии, причем для синхронизации потоков всехопераций по каждому подписчику применяется контрольное перепроведение документав эталонной БД, таким образом, на подписчике при проведении документаназначается статус «предварительно проведен», а на эталонной базе«проведен».
6. Гибкая процедураразрешения конфликтов — репликация позволяет отслеживатьконфликты (под конфликтом понимаем состояние, когда 2 или более подписчиковсодержат транзакции по изменению одного и того же объекта) по основным типамобъектов (справочники, документы), правильно их разрешать, легировать инотифицировать.
Важность и необходимость процессарепликации лучше всего иллюстрируются примером. Представим себе крупнуютуристическую фирму, имеющую головной офис и несколько филиалов, расположенныхв гостиницах. И в головном офисе, и в филиалах работает программа формированияи учета оказываемых услуг, причем и там, и там постоянно происходят обновления,которые должны быть доступны на всех рабочих местах, в реальном времени(выставленные счета, специальные предложения, изменения в цене и т. д.). Как вэтом случае обновлять базы данных?
При решении проблемы простым путёмменеджер в филиале составляет документ, отражающий изменения, посылает егослужбе поддержки работы базы, а там вносят изменения в базу на основе этогодокумента. Это не решение — это выход из положения, абсолютно не оправдывающийсебя при большом объеме изменений. В перспективе же это создание трудностей дляпоследующей героической борьбы с ними.
Почти идеальное с технической точкизрения решение: соединить головной офис и филиалы скоростными каналами связи исделать базу данных единой для программы учета. Этот путь возможен толькотогда, когда все филиалы имеют постоянный доступ в Интернет по локальной сетиили выделенной линии. Что происходит в случае обрыва соединения? Очевидно, чтобесперебойной работы в этом решении не добиться. Кроме того, естьпсихологический аспект, преодолеть который, скорее всего, не удастся:руководство компании будет очень испугано появлением принципиальной возможностизайти из Интернета в «святая святых» — базу данных программы учета. Ивряд ли рассказы о межсетевых экранах и прочих средствах безопасности егоуспокоят.
Применение ПК «Репликацияинформационных баз» полностью выполняет требование «в реальномвремени». Т.е. оператор филиала создаёт / изменяет объект репликации(справочник или документ) и все остальные операторы могут тут же увидеть этуинформацию.
В случае обрыва связи информационнаябаза работает в автономном режиме, и как только соединение будет восстановлено,- данные будут синхронизированы.
Данное решение не требует участиячеловека в процессе обмена (не надо выгружать/загружать файлы и т.д.) и нетребует вносить изменения в конфигурацию.
Передаётся только та информация,которая необходима, таким образом, трафик обмена незначителен. Репликация такжеможет решить проблему резервного копирования и проблему архивации (когда базаразбивается на текущую и архив).
2.1 О репликации базы данных
Современныеинформационные системы предъявляют достаточно высокие требования к скоростиотработки информации при условии одновременной работы большого количестваклиентов. Кроме того, развиваясь, такие системы должны легко масштабироватьсябез ущерба для скоростных характеристик системы.
Одиниз способов удовлетворения этой потребности — создание распределенной базыданных БД, поддерживающей механизм асинхронной репликации данных. В этом случаевместо одной БД, с которой должны работать все клиенты информационной системы,создается несколько одинаковых серверов БД на разных машинах и/или узлах сети.Клиенты имеют доступ к некоторому распределяющему устройству (реализованномуаппаратно или программным методом), которое при подключении нового клиентаоценивает загрузку каждого сервера БД и направляет клиента к наименеезагруженному серверу, с которым он (клиент) и будет работать до отсоединения.
Вопросыпостроения распределенной базы данных единой информационной системы возникают ипри развитии компании, когда создаются удаленные филиалы, магазины и склады.Каждая удаленная информационная система с целью повышения устойчивости должнаработать самостоятельно, периодически отправляя в Центральный офисконсолидированную информацию. Для исключения человеческого фактора в вопросепериодической синхронизации информации базы данных должны быть включены в общуюсистему репликации.
Репликацияданных между серверами баз данных может выполняться с помощью встроенныхсредств СУБД или может быть реализована в рамках бизнес — логики приложений.Репликация с помощью встроенных средств СУБД предполагает наличие надежныхканалов связи. Пропускная способность этих каналов должна быть достаточновысокой, чтобы успевать передавать всю реплицируемую информацию вrealtime-режиме. Процесс репликации в СУБД основан на понятиях«издатель», «подписчик», «статья». Настройка репликациисводится к установке отношений между издателем и подписчиком. Недостаткомданной репликации является однонаправленность. Т.е. статья (фактически этотаблица) может передаваться от издателя подписчику. При этом подписчик не можетее изменять.
Реализациипроцессов репликации на уровне бизнес-логики значительно усложняет жизньразработчику, но позволяет значительно оптимизировать сам процесс передачиинформации. Проблема репликации информации представляет собой довольнонетривиальную задачу с весьма неоднозначным решением. Приступая к решениюзадачи репликации данных, необходимо принимать во внимание, что придетсястолкнуться с конфликтами реплицируемых данных, которых для баз данных,работающих в единой сети прямого коннекта к серверу базы данных, не возникает впринципе. Особенно сложен переход от единой базы к распределенной, когдаприходится подстраивать алгоритм репликации под уже существующую структуруработающей БД. При разработке новой информационной системы необходимо учитыватьтехнологические нюансы будущей распределенной базы данных.
2.2Механизмы репликации данных
Для поддержкицелостности распределенной БД в СУБД ЛИНТЕР используется механизм асинхронноготиражирования (далее по тексту — репликации) транзакций.
Суть механизмаасинхронного тиражирования состоит в том, что обработка данных выполняетсялокально, а распределенные данные копируются на тот сервер, где они должныиспользоваться. При таком методе поддержки логической целостностираспределенной БД имеет место некоторая рассинхронизация состояния локальных БДво времени, т.е. изменение состояния одной локальной базы данных отстает отизменения другой локальной базы данных во времени.
Если один из серверовсистемы, требующих обновления тиражируемых данных, выходит из строя, то системапродолжает работать с остальными, при этом обновление данных на сервере послеего ремонта произойдет автоматически, т.е. ошибка на одном узле глобальной сетине повлияет на работу остальных узлов.
Механизм асинхронноготиражирования транзакций гарантирует доставку измененных данных на вторичныесерверы непосредственно после завершения транзакции, если сервер доступен, илисразу после подключения сервера к сети. Такой подход предполагает хранениедублирующей информации в различных узлах сети и может обеспечить, по сравнениюс другими подходами к репликации, снижение трафика, улучшение времени ответасистемы, а также позволяет оптимизировать нагрузку на серверы.
Асинхронная репликация,в отличие от двухфазной синхронизации, не обеспечивает полной синхронностиинформации на всех серверах в любой момент времени. Синхронизация происходитчерез некоторый, обычно небольшой, интервал времени, величина которогоопределяется быстродействием соответствующего канала связи. Для большинствазадач кратковременное наличие устаревших данных в удаленных узлах вполнедопустимо.
Вместе с тем,асинхронная репликация транзакций принципиально обеспечивает целостностьданных, так как объектом обмена данными здесь является логическая единицаработы — транзакция, а не просто данные из измененных таблиц.
2.3Назначение репликации данных
Многие современныеинформационные системы предъявляют достаточно высокие требования к скоростиотработки поисковых запросов при условии одновременной работы большогоколичества клиентов. Кроме того, развиваясь, такие системы должны легкомасштабироваться без ущерба для скоростных характеристик системы.
Один из способовудовлетворения этой потребности — создание распределенной базы данных (БД),поддерживающей механизм асинхронной репликации данных. В этом случае вместоодной БД, с которой должны работать все клиенты информационной системы,создается несколько одинаковых (по крайней мере, частично) серверов БД наразных машинах и/или узлах сети. Клиенты имеют доступ к некоторому распределяющемуустройству (реализованному аппаратно или программным методом), которое припоявлении нового клиента оценивает загрузку каждого сервера БД и направляетклиента к наименее загруженному, с которым он (клиент) и будет работать доотсоединения.
Сервера БД связанымежду собой и все сделанные изменения пересылают друг другу (тиражируют) с тем,чтобы привести реплицируемые объекты (таблицы) в полное соответствие. Посколькурепликация асинхронная, то этот процесс происходит не сразу, а в течениенекоторого времени, в ходе которого данные на разных серверах будут отличаться.
Такое построениепозволяет значительно (в самом лучшем случае, прямо пропорционально количествусерверов БД) увеличить производительность системы и наращивать ее по мере ростанагрузки (увеличения количества клиентов или размеров БД) простым прибавлениемсерверов БД в информационную систему.
Для управления системойна логическом уровне используются правила репликации, которые создаются спомощью языка БД SQL и представляют собой описание того, какие объекты, куда икаким образом реплицировать.
/>/>2.4Функциональные требования к серверу репликации
Приразработке сервера репликации были определены основные требования, которым ондолжен удовлетворять:
· совмещениефункции сервера публикации и сервера подписки;
· исключениенарушения структуры базы данных;
· использованиев гетерогенной (смешанной) системе, т.е. система репликации может включатьсервера баз данных как Oracle, так и MS SQL;
· многонаправленнаярепликация с гарантированной доставкой информации, т.е. сервер публикациидолжен рассылать информацию нескольким серверам подписки;
· серверподписки может принимать информацию от нескольких серверов публикации;
· системарепликации может представлять сложную паутину, в которой отдельные серверарепликации, совмещая функции сервера подписки и сервера публикации, выполняютфункцию сервера пересылки информации;
· наглядныйвизуальный контроль функционирования сервера репликации как в режимепубликации, так и в режиме подписки;
· репликацияинформации таблиц, структура которых включает поля BLOB (binary large object) иполя, допускающие значение NULL;
· кодированиереплицируемой информации.
Серверрепликации удовлетворяет не только этим требованиям, но и имеет еще ряддополнительных функций, которые позволяют наглядно контролировать процессрепликации, устанавливать и контролировать параметры канала соединения судаленными серверами, выполнять экспортно/импортные операции для доставки информациина жестких носителях и загрузки ее в сервер подписки при отсутствии каналасвязи.
Серверлицензии,входящий в комплектацию сервера репликации, обеспечивает дополнительную защитуреплицируемой информации. Система репликации замкнутая, и сервер лицензии непозволяет серверу подписки подключиться к серверу публикации другойинформационной системы, а также отказывает в доступе серверам публикации другихинформационных систем.
2.5Синхронная репликация
В случае синхронной репликации,если данная реплика обновляется, все другие реплики того же фрагмента данныхтакже должны быть обновлены в одной и той же репликации. Логически этоозначает, что существует лишь одна версия данных.
В большинстве продуктовсинхронная репликация реализуется с помощью триггерных процедур (возможно,скрытых и управляемых системой). Но синхронная репликация имеет тот недостаток,что она создаёт дополнительную нагрузку при выполнении всех транзакций, вкоторых обновляются какие-либо реплики (кроме того, могут возникать проблемы,связанные с доступностью данных).
2.6Асинхронная репликация
В случае асинхроннойрепликации обновление одной реплики распространяется на другие спустя некотороевремя, а не в той же транзакции. Таким образом, при асинхронной репликациивводится задержка, или время ожидания, в течение которого отдельные репликимогут быть фактически неидентичными (то есть определение реплика оказывается несовсем подходящим, поскольку мы не имеем дело с точными и своевременносозданными копиями).
В большинстве продуктовасинхронная репликация реализуется посредством чтения журнала транзакций илипостоянной очереди тех обновлений, которые подлежат распространению.Преимущество асинхронной репликации состоит в том, что дополнительные издержкирепликации не связаны с транзакциями обновлений, которые могут иметь важноезначение для функционирования всего предприятия и предъявлять высокиетребования к производительности.
2.7Основные принципы, правила построения и функционирования РБД
РБД состоит из набораузлов, связанных коммуникационной сетью, основной задачей которой являетсяпередача данных без ошибок и искажения. Коммуникационная сеть является ядром информационнойсети, обеспечивающим передачу и некоторые виды обработки данных.
Коммуникационной сетиприсущи следующие свойства:
1. каждыйузел-это полноценная СУБД сама по себе;
2. узлывзаимодействуют между собой таким образом, что пользователь любого из них можетполучить доступ к любым данным в сети так, как будто они находятся на егособственном узле.
Каждый узел сам по себеявляется СУБД. Любой пользователь может выполнить операции над данными на своёмлокальном узле точно так же, как если бы этот узел вовсе не входил враспределённую систему. Распределённую систему баз данных можно рассматриватькак партнёрство между отдельными локальными СУБД на отдельных локальных узлах.
Дадим следующееопределение: распределенная база данных- это набор файлов (отношений),хранящихся в разных узлах информационной сети и логически связанных такимобразом, чтобы составлять единую совокупность данных (связь может бытьфункциональной или через копии одного и того же файла).
Распределенная базаданных предполагает хранение и выполнение функций управления данными в несколькихузлах и передачу данных между этими узлами в процессе выполнения запросов.Разбиение данных в распределенной базе данных может достигаться путем храненияразличных таблиц на разных компьютерах или даже хранения разных частей ифрагментов одной таблицы на разных компьютерах. Для пользователя (илиприкладной программы) не должно иметь значения, каким образом распределеныданные между компьютерами. Работать с распределенной базой данных, если онадействительно распределенная, следует так же, как и с централизованной, т. е.размещение базы данных должно быть прозрачно.
Несмотря на то, чтораспределенная база данных состоит из нескольких локальных баз данных, упользователя должна сохраняться иллюзия работы с централизованной базой данных,что вызывает потребность в использовании некоторого общего представления оданных — глобальной концептуальной схемы. Определение данных в такойконцептуальной схеме должно быть аналогичным определению в централизованнойбазе данных.
Отличия начинаются,когда требуется хранить данные в нескольких узлах. Чтобы произвести разбиениеданных, нужно секционировать таблицы глобальной схемы на фрагменты. Существуетдва типа секционирования: горизонтальное и вертикальное. При секционированиитаблицы по строкам выполняется горизонтальное секционирование, при разбиении постолбцам вертикальное.
Таким образом,архитектура распределенной СУБД должна содержать информацию о секционированииисходных таблиц базы данных, что предполагает создание дополнительного уровня — фрагментного.
Самый высший уровень архитектурыраспределенной СУБД — это интерфейс прикладной программы и интерфейс процессоразапросов.
Взгляд на базу данныхотдельных пользователей представлен в архитектуре отдельным 1-м уровнем, чтоаналогично внешнему уровню в классической архитектуре СУБД.
Для реализации иобъяснения распределенной природы базы данных выделяются два уровня:фрагментный и уровень распределенного представления. Последний показываетгеографическое распределение данных по рабочим станциям, расположение экземпляракаждого фрагмента.
1-4 уровни архитектурыраспределенной СУБД относятся к сетевой СУБД.
Однако выделяют ещелокальные СУБД, где определяют представление данных на каждой рабочей станции.
Каждый уровеньподдерживает различные представления базы данных; каждый уровеньвзаимодействует только со смежными уровнями представления.
Для управленияраспределенной базой данных создается программный комплекс — система управленияраспределенной базой данных (СУРБД).
C. J. Date в 1987 годусформулировал один основной принцип и двенадцать правил, которым, по егомнению, должны следовать распределенные базы данных .
Основной принципзаключается в «прозрачности распределенности». С точки зренияпользователя информации распределенная БД не должна отличаться от локальной БД.Здесь имеется в виду пользователь, формулирующий запросы к базе данных иполучающий результаты на своем экране (или принтере). Технология его работы недолжна зависеть от того, в какой конкретной базе находятся нужные ему данные: вего локальной базе, в удаленной базе, все необходимые данные в одной и той жебазе или в различных базах данных.
Фундаментальный принципимеет следствием определённые дополнительные правила или цели. Таких целейвсего двенадцать:
1. Локальнаянезависимость. Узлы в распределённой системе должны быть независимы, илиавтономны. Локальная независимость означает, что все операции на узлеконтролируются этим узлом.
2. Отсутствиеопоры на центральный узел. Локальная независимость предполагает, что все узлы враспределённой системе должны рассматриваться как равные. Поэтому не должнобыть никаких обращений к «центральному» или «главному» узлу с целью получениянекоторого централизованного сервиса.
3. Непрерывноефункционирование. Распределённые системы должны предоставлять более высокуюстепень надёжности и доступности.
4. Независимостьот расположения. Пользователи не должны знать, где именно данные хранятсяфизически и должны поступать так, как если бы все данные хранились на ихсобственном локальном узле.
5. Независимостьот фрагментации (дробления данных на множество мелких разрозненных фрагментов).Система поддерживает независимость от фрагментации, если даннаяпеременная-отношение может быть разделена на части или фрагменты приорганизации её физического хранения. В этом случае данные могут храниться в томместе, где они чаще всего используются, что позволяет достичь локализациибольшинства операций и уменьшения сетевого трафика.
6. Независимостьот репликации. Система поддерживает репликацию данных, если данная хранимаяпеременная-отношение — или в общем случае данный фрагмент данной хранимойпеременной-отношения — может быть представлена несколькими отдельными копиямиили репликами, которые хранятся на нескольких отдельных узлах.
7. Обработкараспределённых запросов. Суть в том, что для запроса может потребоватьсяобращение к нескольким узлам. В такой системе может быть много возможныхспособов пересылки данных, позволяющих выполнить рассматриваемый запрос.
8. Управлениераспределёнными транзакциями (последовательность операций, представляющая собойлогическую единицу работы с данными). Существует 2 главных аспекта управлениятранзакциями: управление восстановлением и управление параллельностьюобработки. Что касается управления восстановлением, то чтобы обеспечитьатомарность транзакции в распределённой среде, система должна гарантировать,что все множество относящихся к данной транзакции агентов (агент — процесс,который выполняется для данной транзакции на отдельном узле) или зафиксировалосвои результаты, или выполнило откат. Что касается управления параллельностью,то оно в большинстве распределённых систем базируется на механизмеблокирования, точно так, как и в нераспределённых системах.
9. Аппаратнаянезависимость. Желательно иметь возможность запускать одну и ту же СУБД наразличных аппаратных платформах и, более того, добиться, чтобы различные машиныучаствовали в работе распределённой системы как равноправные партнёры.
10. Независимостьот операционной системы. Возможность функционирования СУБД под различнымиоперационными системами.
11. Независимостьот сети. Возможность поддерживать много принципиально различных узлов,отличающихся оборудованием и операционными системами, а также ряд типовразличных коммуникационных сетей.
12.Независимость оттипа СУБД. Необходимо, чтобы экземпляры СУБД на различных узлах все вместеподдерживали один и тот же интерфейс, и совсем необязательно, чтобы это быликопии одной и той же версии СУБД.
Локальная автономияозначает, что управление данными на каждом из узлов распределенной системы выполняетсялокально. База данных, расположенная на одном из узлов, является неотъемлемымкомпонентом распределенной системы. Будучи фрагментом общего пространстваданных, она в то же время функционирует как полноценная локальная база данных;управление ею выполняется локально и независимо от других узлов системы.
Независимость отцентрального узла означает, что в идеальной системе все узлы равноправны инезависимы, а расположенные на них базы являются равноправными поставщикамиданных в общее пространство данных. База данных на каждом из узловсамодостаточна: она включает полный собственный словарь данных и полностьюзащищена от несанкционированного доступа.
Непрерывные операцииможно трактовать как возможность непрерывного доступа к данным (известное 24 часав течение суток, семь дней в неделю) в рамках DDB вне зависимости от ихрасположения и вне зависимости от операций, выполняемых на локальных узлах. Этокачество можно выразить лозунгом данные доступны всегда, а операции над нимивыполняются непрерывно.
Прозрачностьрасположения означает полную прозрачность расположения данных. Пользователь,обращающийся к DDB, ничего не должен знать о реальном, физическом размещенииданных в узлах информационной системы. Все операции над данными выполняются безучета их местонахождения. Транспортировка запросов к базам данныхосуществляется встроенными системными средствами.
Прозрачная фрагментациятрактуется как возможность распределенного (то есть на различных узлах)размещения данных, логически представляющих собой единое целое. Существуетфрагментация двух типов: горизонтальная и вертикальная. Первая означаетхранение строк таблицы на различных узлах (фактически, хранение строк однойлогической таблицы в нескольких идентичных физических таблицах на различныхузлах). Вторая означает распределение столбцов логической таблицы по несколькимузлам.
Прозрачностьтиражирования (асинхронного в общем случае процесса переноса изменений объектовисходной базы данных в базы, расположенные на других узлах распределеннойсистемы) означает, что тиражирование возможно и достигается внутрисистемнымисредствами.
Обработкараспределенных запросов DDB трактуется как возможность выполнения операцийвыборки над распределенной базой данных, сформулированных в рамках обычногозапроса на языке SQL. To есть операцию выборки из распределенной базы данныхможно сформулировать с помощью тех же языковых средств, что и операцию надлокальной базой данных. Оптимизатор распределенных запросов учитывает такиепараметры, как размер таблиц, статистику распределения данных по узлам, объемданных, передаваемых между узлами, скорость коммуникационных линий, структурыхранения данных, соотношение производительности процессоров на разных узлах ит. д. От алгоритмов работы оптимизатора распределенных запросов впрямую зависитскорость работы базы данных с такими запросами.
Обработкараспределенных транзакций DDB можно трактовать как возможность выполненияопераций обновления распределенной базы данных (INSERT, UPDATE, DELETE), неразрушающее целостность и согласованность данных. Эта цель достигаетсяприменением двухфазового или двухфазного протокола фиксации транзакций(two-phase commit protocol), ставшего фактическим стандартом обработкираспределенных транзакций. Его применение гарантирует согласованное изменение данныхна нескольких узлах в рамках распределенной, или глобальной транзакции.
Независимость отоборудования означает, что в качестве узлов распределенной системы могутвыступать компьютеры любых моделей и производителей — от мэйнфреймов доперсоналок.
Независимость отоперационных систем как качество вытекает из предыдущего и означаетмногообразие операционных систем, управляющих узлами распределенной системы.
Прозрачность сетиозначает, что спектр поддерживаемых конкретной СУБД сетевых протоколов недолжен быть ограничением системы с распределенными базами данных. Данноекачество формулируется максимально широко: в распределенной системе возможнылюбые сетевые протоколы.
Независимость от базданных означает, что в распределенной системе могут мирно сосуществовать СУБДразличных производителей, и возможны операции поиска и обновления в базахданных различных моделей и форматов.
репликациясинхронизация база данные
ЗАКЛЮЧЕНИЕ
В основе любыхтехнологических потрясений лежит простой экономический расчет:выгодно — невыгодно. В основе нынешней ситуации в развитии распределенныхсистем также лежит экономическое обоснование — стоимость передачи данных посети становится меньше стоимости вычислений на клиентской машине и этатенденция имеет устойчивый характер. Взрывной рост Internet, который многиесвязывают с «демократическими свободами» или развитием новойтехнологии имеет в своей основе все тоже простое экономическое обоснование — эта технология экономически выгодна. Отсюда проистекают и те изменения в миретехнологий свидетелями которых мы являемся: стремительный рост пропускнойспособности каналов (Internet — 2, новые более быстрые модемы, спутниковыеканалы для домашнего пользователя ), присутствие в сети большинства корпорацийи масс медиа, электронная коммерция и банки … На основе этих технологий вырослиновые направления бизнеса, а распространенность Internet растет темпаминевиданными в отрасли (быстрее телефонии и телевидения).
/>СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ
1. BorlandInter Base Workgroup Server. API Guide. — Borland International
Inc,1995-330c.
2. BorlandInter Base Workgroup Server. Data Definition Guide. – Borland
InternationalInc,1995-212c.
3. BorlandInter Base Workgroup Server. Language Reference. – Borland
InternationalInc,1995-234c.
4. BorlandInter Base Workgroup Server. Programmer’s Guide. – Borland
InternationalInc,1995-340c.
5. MicrosoftOnline Documentation: Win32 Programmers Reference.
6. R.Barker«CASE* Method — Entity Relationship Modelling». — Oracle Inc.1990-243c.
7. Биллиг В.А., Мусикаев И.Х. «Visual C++ 4. Книга для программистов». М.:Издательский отдел «Русская редакция» ТОО.
8. Галатенко В.«Информационная безопасность — обзор основных положений: Ч1»: — Информационный бюллетеньJet Info №1/1996.
9. Галатенко В.«Информационная безопасность — обзор основных положений: Ч2»: — Информационныйбюллетень Jet Info №2/1996.
10. Галатенко В.«Информационная безопасность — обзор основных положений: Ч3»: — Информационныйбюллетень Jet Info №3/1996.
11. Грабер Мартин.“Введение в SQL”. Пер. с англ. — М.: Издательство “ЛОРИ”,1996.-375с., ил.
12. Зубанов Ф.«Windows NT — выбор «профи»». — М.: Издательский отдел «Русская редакция» ТОО«Channel Trading Ltd.», 1996. — 392 с. ил.
13. Кастер Х. «ОсновыWindows NT и NTFS». Пер. с англ. — М: Издательский отдел «Русская редакция» ТОО«Channel Trading Ltd.», 1996.-440с.ил.
14. Ладыженский Глеб.«СУБД — коротко о главном» — Информационный бюллетень.
15. Ларин Л.С.,Челдаева Л.А., Гуськова Н.Д. «Технико-экономическое обоснование дипломныхпроектов», Саранск, 1983, 100 с.
16. «РешенияMicrosoft» — Вып. 5. — М: АООТ «Типография Новости», 1997.132с., ил.
17. Рихтер Дж…«Windows для профессионалов (Программирование в Win32 API для Windows 95 иWindows NT)». Пер. с англ. «Русская редакция» ТОО «Channel Trading Ltd.»,1995. — 720 с. ил.
18. Паппас К., МюррейУ… «Visual C++. Руководство для профессионалов»: пер. с англ. — Спб.: BHV — Санкт-Петербург,1996. — 912 с., ил.
19. «Сетевые средстваWindows NT»: Пер. с англ. — СПб.: BHV — Санкт- Петербург,1996-496с., ил.