Фуфаев - Разработка и эксплуатация удалённых БД (1084483), страница 20
Текст из файла (страница 20)
Многозвенное приложение представляет собой распределенные системы удаленного доступа к данным, которые состоят, как минимум, из трех логических уровней. Эти логические уровни могут находиться как на одном, так и на нескольких компьютерах. Применение многозвенных приложений позволяет обеспечить следующие преимушества: ° формирование пакета бизнес-логики в общедоступном среднем уровне, доступ на который могут получить одновременно сразу 98 несколько клиентов, что позволит избежать дублирования бизнес-логики для каждого отдельного клиентского приложения; ° получение распределенной обработки информации, т.е.
возможность оптимизации распределения нагрузки на отдельные компьютеры; * увеличение устойчивости за счет возможности организации гибкой перестраиваемой системы защиты информации. В самой простой форме (так называемой гпгее-бегед шойе!) многозвенное приложение включает в себя следующие уровни: клиентское приложение, сервер приложений, управление передачей данных и удаленный сервер базы данных. ллиенгпское приложение обеспечивает интерфейс пользователя на пользовательском компьютере. Сервер приложений находится в доступном для всех клиентов месте и обеспечивает общую передачу данных.
Управление передачей данных обеспечивает так называемый брокер данных. Удаленный сервер базы данных обеспечивает систему управления базой данных. Взаимодействие указанных уровней осуществляется следующим образом. Е Пользователь запускает клиентское приложение. 2.,Клиент соединяется с сервером приложений (который может определяться как во время исполнения, так и во время создания приложения). 3. Запускается сервер приложений.
4. Клиент получает интерфейс )АррБегтег от сервера приложений. 5. Клиент запрашивает данные из сервера приложений, который, в свою очередь, запрашивает информацию из базы данных, упаковывает ее для клиента и возвращает пакет данных клиенту, 6. Клиент расшифровывает пакеты данных и предоставляет их пользователю. 7. Пользователь взаимодействует с клиентским приложением. При изменении данных клиент упаковывает измененные данные в пакеты и отсылает их на сервер приложений. 8.
Сервер приложений расшифровывает пакеты и сохраняет изменения в контексте транзакции. Если запись не может быть сохранена на сервере, последний пытается согласовать изменения с текущими данными и отделяет данные, которые не могут быть сохранены. Когда процесс обработки измененных данных закончен, сервер возвращает все несохраненные данные клиенту для дальнейшего уточнения. 9. Клиент уточняет необработанные данные, после чего посылает их снова серверу приложений. Затем клиент обновляет свои данные с сервером. 99 Разработка пользовательских приложений производится с применением языка программирования Ре!рЬ!.
Технология М1РАЯ позволяет: ° получать доступ к данным, физически расположенным на разных машинах; ° распределять нагрузку ресурсов по сети, что позволяет уменьшить сетевой трафик; ° разделить бизнес-логику приложения на отдельные части, что повышает уровень безопасности работы с базами данных. Эффективную разработку приложений М1РАВ обеспечивают следующие основные компоненты: ° модули удаленных данных; ° компонент ТС1!епгРагабег набора данных клиента; ° компоненты связи ТРСОМСоппесг!оп, ТЯоскегСоппесг!оп, Т%еЬСоппесг!оп, ТСогЬаСоппесйоп; ° брокер бизнес-объектов Ягпр!еОЬ!есгВгохег.
Модули удаленных данных — это специальные модули данных, которые действуют как серверы автоматизации или как СОКВА- серверы, предоставляя клиентам доступ к любым провайдерам, которые они содержат. Используются на сервере приложений. Компонент набора данных клиента ТС1!епгРасабес — это специализированный набор данных, который использует М1РАБ .РП.
для управления. Компоненты связи ТРСОМСоппесйоп, ТЯос1сегСоппесг!оп, Т%еЬСоппесг!оп, ТСогЬаСоппесйоп — это набор компонентов, которые определяют сервер приложений, тип взаимодействия между клиентом и сервером и формируют интерфейс, доступный для наборов данных клиента. Каждый из этих компонентов специализируется на конкретном протоколе связи. Брокер бизнее-обьектов Ягпр1еОЬ!есгВго!гег служит для распределения вычислительной нагрузки по нескольким серверам. С помощью технологии М1РАБ можно создавать системы, которые могут обрабатывать запросы Интернет-приложений.
М1РАБ работает одинаково хорошо с технологиями СОКВА, СОМ, 01.Епгегрпзе и МТЯ и упрощает интеграцию существующих систем. Контрольные вопросы !. В чем состоит принципиальное отличие двухуровневой клиент-серверной схемы организации баз данных от трехуровневой? 2. Что означают понятия «объектная модель» н «объектная архитектура»? 3. Какие задачи выполняет программа Монитор обработки транзакций? 4. Каковы основные причины популярности системы доступа к удаленным базам данных? 5.
Рекомендуетсл лн применять технологию удаленного доступа к данным в сети Интернет? !ОО 6. Для решения каких задач применяют технологию удаленного доступа к данным АОО .19ЕТ? 7. Поясните схему работы клиента с сервером баз данных в технологии АОО .МЕТ. 8. Какая технология доступа к данным в среде Интернет была разработана в АОО,НЕТ? 9. Из каких компонентов состоит среда ЛЧЕТ Ргаше%ог1г? 10.
Для каких целей применяют технологию доступа к данным СОЕВА? 11. Каково назначение следуюших компонентов системы СОКВА: ОВВ, 1ОЬ, РОА, Яцб, Я~е1егоп, Бтан Адепт? 12. Для чего рекомендуется применять технологии доступа к данным М1ОАВ? ЧАСТЬ И ПРОЕКТИРОВАНИЕ СЕРВЕРНОЙ ЧАСТИ ПРИЛОЖЕНИЯ БАЗ ДАННЫХ глдвд у МЕТОДИЧЕСКИЕ ОСНОВЫ ПРОЕКТИРОВАНИЯ СЕРВЕРНОЙ ЧАСТИ ПРИЛОЖЕНИЯ Методология разработки серверной части приложения предусматривает разбиение всего процесса проектирования на концептуальное, логическое и физическое. Коицеитуальиое проектирование Йи даииых должно отражать единую информационную модель предприятия, не зависящую от программных и технических условий реализации информационной системы. Концептуальное проектирование базы данных включает в себя следующие этапы.
1. Создание локальной концептуальной модели данных. 2. Определение типов сущностей. 3. Определение атрибутов. 4. Определение типов связей. 5. Проверка модели на избыточность. 6. Проверка соответствия локальной концептуальной модели конкретным пользовательским транзакциям. 7. Обсуждение локальных концептуальных моделей данных с конечными пользователями. Создание локальной концептуальной модели данных. Целью данного этапа является определение предметной области и состава пользователей разрабатываемой базы данных. На рис. 7.1 показан пример локальной концептуальной модели, устанавливающей предметную область и связи между подразделениями предприятия в процессе изменения конструкторской документации в разработанной базе данных «Извешение».
П р и м е ч а н и е. База данных «Извещение» была разработана для информационной поддержки процесса принятия решений на изменение конструкторской документации (КД) в процессе жизненного цикла изделий, а также для автоматизированного составления извешений на эти 102 Мероприятия по корректировке технической документации Отдел главного конструктора Отдел материально- технического снабжения Оформление изменения технической документации КБ-л КБ-1 КБ-2 Заказчик Сведение о необходимости корректировки технической документации Отдел главного технолога Утверждение изменения Цеха Химико- металлургиче- скос отделение Регистрация изменения Единый отдел технической документации (ЕОТД) Планово- диспетчерский отдел Планово- зкономическнй отдел Корректиров ка технической документации Передача информации об изменении в ЕОТД Рнс.
7.1. Структура связей между подразделениями приборостроительно- го предприятия Определение типов сущностей. Цель данного этапа сводится к установлению оптимального состава таблиц базы данных в соответствии с задачами каждого конкретного пользователя и с учетом принципов нормализации. Определение атрибутов. На данном этапе для каждой таблицы БД устанавливается необходимый состав атрибутов (признаков), описывающий конкретную сущность, а также необходимые ключевые поля. Определение типов связей. На данном этапе устанавливаются связи между таблицами баз данных в целях обеспечения целостности информации при различных ее модификациях. На рис.
7.2 показан пример, отражающий типы сущностей, н соответствующий состав таблиц и связей между ними в базе данных «Извещение». Проверка модели на избыточность. На данном этапе база данных проверяется на избыточность связей и производится ее устранение в случае обнаружения. Связь является избыточной, если представленная в таблице информация может быть получена нз другой таблицы базы дан- 103 изменения.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
