<< Пред. стр.

стр. 13
(общее количество: 18)

ОГЛАВЛЕНИЕ

След. стр. >>

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

НО
7.7. В чем состоят основные особенности
архитектуры «клиент-сервер»?
Новая модель взаимодействия компьютеров в сети получила
название «клиент-сервер». Каждый из составляющих эту архитек­
туру элементов играет свою роль: сервер владеет и распоряжается
информационными ресурсами системы, клиент имеет возможность
воспользоваться ими.
Сервер базы данных представляет собой мультипользовательс­
кую версию СУБД, параллельно обрабатывающую запросы, по­
ступившие со всех рабочих станций. В его задачу входит реализа­
ция логики обработки транзакций с применением необходимой
техники синхронизации — поддержки протоколов блокирования
ресурсов, обеспечение, предотвращение и/или устранения тупи­
ковых ситуаций.
В ответ на пользовательский запрос рабочая станция получит
не «сырье» для последующей обработки, а готовые результаты.
Программное обеспечение рабочей станции при такой архитек­
туре играет роль только внешнего интерфейса (Front — end)
централизованной системы управления данными. Это позволяет
существенно уменьшить сетевой трафик, сократить время на ожи­
дание блокированных ресурсов данных в мультипользовательс-
ком режиме, разгрузить рабочие станции и при достаточно мощ­
ной центральной машине использовать для них более дешевое
оборудование.
Как правило, клиент и сервер территориально отделены друг
от друга, и в этом случае они входят в состав или образуют
систему распределенной обработки данных.
Для современных СУБД архитектура «клиент-сервер» стала фак­
тически стандартом.
Если предполагается, что проектируемая информация будет
иметь архитектуру «клиент-сервер», то это означает, что при­
кладные программы, реализованные в ее рамках, будут иметь
распределенный характер, т. е. часть функций приложений будет
реализована в программе-клиенте, другая — в программе-сервере.
Основной принцип технологии «клиент-сервер» заключается в раз­
делении функций стандартного интерактивного приложения на
четыре группы:
• функции ввода и отображения данных;
• прикладные функции, характерные для предметной области;
• фундаментальные функции хранения и управления ресур­
сами (базами данных);
• служебные функции.
Исходя из этого деления любое приложение может состоять
из следующих компонентов:
• компонент представления (функции 1-й группы);
• прикладной компонент (функции 2-й группы);
111
• компонент доступа к информационным ресурсам (функции
3-й группы и протокол их взаимодействия).
Различия определяются четырьмя факторами:
• какие виды программного обеспечения в логических ком­
понентах;
• какие механизмы программного обеспечения используются
для реализации функций трех групп;
• как логические компоненты распределяются компьютерами
в сети;
• какие механизмы используются для связи компонент меж­
ду собой.
Исходя из этого, рассмотрим четыре подхода, реализованные
в моделях технологии «клиент-сервер».
1. FS-модель — базовая для локальных сетей персональных ком­
пьютеров. Применялась для разработки информационных систем
на базе FoxPRO, Clipper, Paradox.
Основные свойства:
• выделяется файл-сервер для реализации услуг по обработке
файлов других узлов сети; работает под управлением сетевых ОС;
• играет роль компонент доступа к информационным ресурсам;
• в остальных узлах функционирует приложение, в кодах ко­
торого совмещены компоненты представления и прикладной;
• протокол обмена — набор низкоуровневых вызовов;
Технология: запрос направляется на файловый сервер, кото­
рый передает СУБД, размещенной на компьютере-клиенте, тре­
буемый блок данных. Вся обработка осуществляется на компьюте­
ре-клиенте.
Недостатки:
• высокий сетевой трафик;
• небольшое число операций манипулирования;
• недостаточные требования к безопасности.
2. RDA-модель.
Основные свойства:
• коды компонента представления и прикладного компонен­
та совмещены и выполняются на компьютере-клиенте;
• доступ к информационным ресурсам обеспечивается опера­
торами непроцедурного языка SQL.
Технология:
• клиентский запрос направляется на сервер, где функциони­
рующее ядро СУБД обрабатывает запрос и возвращает результат
(блок данных) клиенту. Ядро СУБД выполняет пассивную роль;
• инициатор манипуляций с данными — программы на ком­
пьютере-клиенте.
Достоинства:
• процессор сервера загружается операциями обработки данных;
• уменьшается загрузка сети, т. к. по сети передаются запросы
на языке SQL;
112
• унификация интерфейса «клиент-сервер» в виде языка SQL;
использование его в качестве стандарта общения клиента и сервера.
Недостатки:
• удовлетворительное администрирование приложений в RDA-
модели невозможно из-за совмещения в одной программе различ­
ных по своей природе функций (представления и прикладных).
3. DBS-модель реализована в реляционных СУБД Informix,
Ingres, Oracle.
Основные свойства:
• основа модель-механизм хранимых процедур — средство про­
граммирования SQL-сервера;
• процедуры хранятся в словаре базы данных, разделяются
между несколькими клиентами и выполняются на компьютере,
где функционирует SQL-сервер;
• компонент представления выполняется на компьютере-клиенте;
• прикладной компонент и ядро СУБД на компьютере-серве­
ре базы данных.
Достоинства:
• возможность централизованного администрирования;
• вместо SQL-запросов по сети передаются вызовы хранимых
процедур, что ведет к снижению сетевого трафика.
Недостатки:
• в большинстве СУБД недостаточно возможностей для от­
ладки и типизирования хранимых процедур;
• ограниченность средств для написания хранимых процедур.
На практике чаще используется разумный синтез RDA- и DBS-
моделей для построения многопользовательских информацион­
ных систем.
4. AS- модель
Основные свойства:
• на компьютере-клиенте выполняется процесс, отвечающий
за интерфейс с пользователем;
• этот процесс, обращаясь за выполнением услуг к приклад­
ному компоненту, играет роль клиента приложения (АС);
• прикладной компонент реализован как группа процессов,
выполняющих прикладные функции, и называется сервером при­
ложения (AS);
• все операции над БД выполняются соответствующим ком­
понентом, для которого AS — клиент.
RDA- и DBS-модели имеют в основе двухзвенную схему раз­
деления функций. В RDA-модели прикладные функции отданы
клиенту, в DBS-модели их реализация осуществляется через ядро
СУБД. В RDA-модели прикладной компонент сливается с компо­
нентом представления, в DBS-модели интегрируется в компонент
доступа к ресурсам.
В AS-модели реализована трехзвенная схема разделения функ­
ций, где прикладной компонент выделен как важнейший изо-
113
лированный элемент приложения, имеющий стандартизирован­
ные интерфейсы с двумя другими компонентами.
AS-модель является фундаментом для мониторов обработки
транзакций.

7.8. Как организуются распределенные
базы данных и технологии работы
с ними?
СУБД и централизация обработки информации позволили уст­
ранить такие недостатки традиционных файловых систем, как не­
связанность, несогласованность и избыточность данных. По мере
роста баз данных и особенно при их использовании в территори­
ально разделенных организациях появляются другие проблемы. Так,
для централизованной СУБД, находящейся в узле телекоммуника­
ционной сети, с помощью которой различные подразделения орга­
низации получают доступ к данным, с ростом объема информации
и количества транзакций возникают следующие трудности:
• большой поток обменов данными;
• низкая надежность;
• низкая общая производительность;
• большие затраты на разработку.
Хотя в централизованной базе данных легче обеспечить безо­
пасность, целостность и непротиворечивость информации при
обновлениях, перечисленные проблемы создают определенные
трудности. В качестве возможного решения этих проблем предпо­
лагается децентрализация данных. При децентрализации достига­
ется:
• более высокая степень одновременности обработки вслед­
ствие распределения нагрузки;
• улучшенное использование данных на местах при выполне­
нии удаленных (дистанционных) запросов;
• меньшие затраты;
• простота управления.
Затраты на создание сети, в узлах которой находятся малые
ЭВМ, гораздо ниже, чем затраты на создание аналогичной систе­
мы с использованием большой ЭВМ.
Дадим следующее определение: распределенная база данных —
это набор файлов (отношений), хранящихся в разных узлах ин­
формационной сети и логически связанных таким образом, что­
бы составлять единую совокупность данных (связь может быть
функциональной или через копии одного и того же файла).
Распределенная база данных предполагает хранение и выпол­
нение функций управления данными в нескольких узлах и пере­
дачу данных между этими узлами в процессе выполнения запро­
сов. Разбиение данных в распределенной базе данных может дос-
114
тигаться путем хранения различных таблиц на разных компьюте­
рах или даже хранения разных частей и фрагментов одной табли­
цы на разных компьютерах. Для пользователя (или прикладной
программы) не должно иметь значения, каким образом распреде­
лены данные между компьютерами. Работать с распределенной
базой данных, если она действительно распределенная, следует
так же, как и с централизованной, т. е. размещение базы данных
должно быть прозрачно.
Несмотря на то, что распределенная база данных состоит из
нескольких локальных баз данных, у пользователя должна сохра­
няться иллюзия работы с централизованной базой данных, что
вызывает потребность в использовании некоторого общего пред­
ставления о данных — глобальной концептуальной схемы. Опреде­
ление данных в такой концептуальной схеме должно быть анало­
гичным определению в централизованной базе данных.
Отличия начинаются, когда требуется хранить данные в не­
скольких узлах. Чтобы произвести разбиение данных, нужно сек­
ционировать таблицы глобальной схемы на фрагменты. Существует
два типа секционирования: горизонтальное и вертикальное. При
секционировании таблицы по строкам выполняется горизонталь­
ное секционирование, при разбиении по столбцам — вертикальное.
Таким образом, архитектура распределенной СУБД должна
содержать информацию о секционировании исходных таблиц базы
данных, что предполагает создание дополнительного уровня —
фрагментного.
Самый высший уровень архитектуры распределенной СУБД —
это интерфейс прикладной программы и интерфейс процессора запросо
Взгляд на базу данных отдельных пользователей представлен в
архитектуре отдельным 1-м уровнем, что аналогично внешнему
уровню в классической архитектуре СУБД.
Для реализации и объяснения распределенной природы базы
данных выделяются два уровня: фрагментный (см. выше) и уро­
вень распределенного представления. Последний показывает гео­
графическое распределение данных по рабочим станциям, распо­
ложение экземпляра каждого фрагмента.
1—4 уровни архитектуры распределенной СУБД относятся к се­
тевой СУБД.
Однако выделяют еще локальные СУБД, где определяют пред­
ставление данных на каждой рабочей станции.
Каждый уровень поддерживает различные представления базы
данных; каждый уровень взаимодействует только со смежными
уровнями представления.
Дейт установил 12 свойств или качеств идеальной распределен­
ной базы данных:
1. Локальная автономия (local autonomy).
2. Независимость узлов (no reliance on central site).
3. Непрерывность операции (continuous operation).
115
4. Прозрачность расположения (location independence).
5. Прозрачная фрагментация (fragmentation independence).
6. Прозрачное тиражирование (replication independence).
7. Обработка распределенных запасов (distributed query
processing).
8. Обработка распределенных транзакций (distributed transaction
processing).
9. Независимость от оборудования (hardware independence).
10. Независимость от операционных систем (operationg system
independence).
11. Прозрачность сети (network independence).
12. Независимость от баз данных (database independence).
Локальная автономия означает, что управление данными на
каждом из узлов распределенной системы выполняется локально.
База данных, расположенная на одном из узлов, является неотъем­
лемым компонентом распределенной системы. Будучи фрагмен­
том общего пространства данных, она в то же время функциони­
рует как полноценная локальная база данных; управление ею вы­
полняется локально и независимо от других узлов системы.
Независимость от центрального узла означает, что в идеаль­
ной системе все узлы равноправны и независимы, а расположен­
ные на них базы являются равноправными поставщиками данных
в общее пространство данных. База данных на каждом из узлов
самодостаточна: она включает полный собственный словарь дан­
ных и полностью защищена от несанкционированного доступа.
Непрерывные операции можно трактовать как возможность не­
прерывного доступа к данным (известное «24 часа в течение суток,
семь дней в неделю») в рамках DDB вне зависимости от их распо­
ложения и вне зависимости от операций, выполняемых на локаль­
ных узлах. Это качество можно выразить лозунгом «данные доступ­
ны всегда, а операции над ними выполняются непрерывно».
Прозрачность расположения означает полную прозрачность рас­
положения данных. Пользователь, обращающийся к DDB, ничего
не должен знать о реальном, физическом размещении данных в
узлах информационной системы. Все операции над данными выпол­
няются без учета их местонахождения. Транспортировка запросов к
базам данных осуществляется встроенными системными средствами.
Прозрачная фрагментация трактуется как возможность распре­
деленного (то есть на различных узлах) размещения данных, логи­
чески представляющих собой единое целое. Существует фрагмента­
ция двух типов: горизонтальная и вертикальная. Первая означает
хранение строк таблицы на различных узлах (фактически, хране­
ние строк одной логической таблицы в нескольких идентичных
физических таблицах на различных узлах). Вторая означает распре­
деление столбцов логической таблицы по нескольким узлам.
Прозрачность тиражирования (асинхронного в общем случае
процесса переноса изменений объектов исходной базы данных
116
в базы, расположенные на других узлах распределенной системы)
означает, что тиражирование возможно и достигается внутрисис­
темными средствами.
Обработка распределенных запросов DDB трактуется как воз­
можность выполнения операций выборки над распределенной ба­
зой данных, сформулированных в рамках обычного запроса на
языке SQL.
Обработка распределенных транзакций DDB можно трактовать
как возможность выполнения операций обновления распределен­
ной базы данных (INSERT, UPDATE, DELETE), не разрушающее
целостность и согласованность данных. Эта цель достигается приме­
нением двухфазового или двухфазного протокола фиксации тран­
закций (two-phase commit protocol), ставшего фактическим стан­
дартом обработки распределенных транзакций. Его применение га­
рантирует согласованное изменение данных на нескольких узлах в
рамках распределенной, или глобальной транзакции.
Независимость от оборудования означает, что в качестве узлов
распределенной системы могут выступать компьютеры любых мо­
делей и производителей — от мэйнфреймов до «персоналок».
Независимость от операционных систем как качество вытека­
ет из предыдущего и означает многообразие операционных сис­
тем, управляющих узлами распределенной системы.
Прозрачность сети означает, что спектр поддерживаемых кон­
кретной СУБД сетевых протоколов не должен быть ограничением
системы с распределенными базами данных. Данное качество фор­
мулируется максимально широко: в распределенной системе воз­
можны любые сетевые протоколы.
Независимость от баз данных означает, что в распределенной
системе могут мирно сосуществовать СУБД различных произво­
дителей, и возможны операции поиска и обновления в базах дан­
ных различных моделей и форматов.
Исходя из определения Дэйта, СУБД в общем случае можно
рассматривать как слабосвязанную сетевую структуру, узлы ко­
торой представляют собой локальные базы данных. Локальные
базы данных автономны, независимы и самоопределены; доступ
к ним обеспечивается от различных поставщиков. Связи между
узлами — это потоки тиражируемых данных. Топология DDB ва­
рьируется в широком диапазоне: возможны варианты иерархии,
структур типа «звезда» и т. д. В целом топология DDB определяется
географией информационной системы и направленностью пото­
ков тиражирования данных.
Рассмотрим теперь проблемы реальных распределенных баз
данных. Проблемы централизованных СУБД существуют и здесь,
однако децентрализация добавляет новые:
а) Какова общая модель данных распределенной системы? Мы
должны иметь единую концептуальную схему всей сети. Это обес­
печит логическую прозрачность данных для пользователя, в ре-
117
зультате чего он сможет формировать запрос ко всей базе, нахо­
дясь за отдельным терминалом (т. е. как бы работая с централизо­
ванной базой данных).
б) Необходима схема, определяющая местонахождение дан­
ных в сети. Это обеспечит прозрачность размещения данных, бла­
годаря которой пользователь может не указывать, куда переслать
запрос, чтобы получить требуемые данные.
в) Распределенные базы данных могут быть однородными или
неоднородными по аппаратным и программным средствам. Про­
блему неоднородности сравнительно легко решить, если распре­
деленная база является неоднородной по аппаратным средствам,
но однородной по программным средствам (одинаковые СУБД в
узлах). Если же в узлах распределенной системы используются
разные СУБД, необходимы средства преобразования структур дан­
ных и языков. Это должно обеспечить прозрачность преобразова­
ния в узлах распределенной базы данных.
г) Управление словарями. Для обеспечения всех видов про­
зрачности в распределенной базе данных нужны программы, уп­
равляющие многочисленными справочниками или словарями.
д) Методы выполнения запросов в распределенной базе дан­
ных отличаются от аналогичных методов централизованных СУБД,
так как отдельные части запроса нужно выполнять на месте рас­
положения соответствующих данных и передавать частичные ре­
зультаты на другие узлы; при этом должна быть обеспечена коор­
динация всех процессов.
е) В распределенной базе данных нужен сложный механизм
управления одновременной обработкой, который, в частности,
должен обеспечивать синхронизацию при обновлениях информа­
ции, то гарантирует непротиворечивость данных.
ж) Развитая методология распределения и размещения дан­
ных, включая разбиение, является одним из основных требова­
ний к распределенной базе данных.


Литература к главе 7
1. Бойко В.В., Савинков В.М. Проектирование баз данных информацион­
ных систем. — М.: Финансы и статистика, 1989.
2.Дмошинский Г.М., СерегинЛ.В. Телекоммуникационные сети России. Опи
сание. Классификация. Выбор. — М.: Архитектура и строительство России, 1993.
3. Информатика: Учебник/ Под ред. проф. Н.В. Макаровой. — М.: Финансы
и статистика, 1997.
4. Иванов Ю.Н. Теория информационных объектов и системы управления
базами данных. — М.: Наука, 1988.
5. Информационные системы в экономике: Учебник / Под ред. проф.
В.В. Дика. — М.: Финансы и статистика, 1996.

118
6. Компьютерные технологии обработки информации: Учеб. пособие /
СВ. Назаров, В.И. Першиков, В.А. Тафинцев и др.; Под ред. СВ. Назарова. —
М.: Финансы и статистика, 1995.
7. Машурцев В.А., Якушева Н.М. Работа пользователя и системного адми­
нистратора с рабочей станцией Windows NT. — М.: Радио и связь, 1999.
8. Турьянский А.Г. Искусство и технология международной связи. — М.:
«Дело Лтд», 1995.
9. Эви Немет, Гарт Снайдер, Скотт Сибасс, Трент Р. Хеш UNIX: руко­
водство системного администратора: Пер. с англ. — К.: BHV, 1997.
10. Эд Крол. Все об Internet.: Пер. с англ. — К.: BHV, 1996.
И.Якушева Н.М., Машурцев В.А. Unix. Коммуникации. — М.: Радио и
связь, 1998.
ГЛАВА 8
ГИПЕРТЕКСТОВЫЕ ТЕХНОЛОГИИ
ОБРАБОТКИ ДАННЫХ

8.1. Что такое гипертекстовые технологии?
Гипертекст (нелинейный текст) — это организация текстовой
информации, при которой текст представляет собой множество
фрагментов с явно указанными ассоциативными связями между
этими фрагментами.
Основная идея гипертекстовых технологий состоит в том, что
поиск документальной информации происходит с учетом множе­
ства взаимосвязей, имеющихся между документами, а значит,
более эффективно, чем при традиционных методах поиска.

<< Пред. стр.

стр. 13
(общее количество: 18)

ОГЛАВЛЕНИЕ

След. стр. >>