Фуфаев - Разработка и эксплуатация удалённых БД (1084483), страница 3
Текст из файла (страница 3)
Обычно этот код записывается с использованием различных языков программирования, таких как С, С++, ЪЪца1 Ваяс и др. Логика обработки данных (1:)а(а Маш рп)айоп 1.оК(с) — это часть кода приложения, которая непосредственно связана с обработкой данных внутри него. Да,,ными управляет собственно СУБД, а для обеспечения доступа к ним используется язык $91..
Лрог(ессор управления данными (Ва(аВаве Мапайег Бумеш Ргосеаяпй) — это собственно СУБД, которая обеспечивает хранение и управление базами данных. В идеале функции СУБД должны быть скрыты от бизнес-логики приложения, однако при рассмотрении архитектуры приложения мы вмделим их в отдельную его часть.
В централизованной архитектуре (Новг-Вазед Ргосеав(пд) указанные части приложения располагаются в единой среде и комбинируются внутри одной исполняемой программы. В децентрализованной архитектуре эти части приложения могут быть по-разному распределены между серверным и клиентским процессами. В зависимости от характера распределений задач можно выделить следующие их модели (рис. 1.2): ° распределенное представление (Р(мпЬцг)оп Ргезепгаг(оп); ° удаленное представление (Келлоге Ргевепгайоп); ° распределенная бизнес-логика (Кепюсе Вив!певв (.оя(с); ° удаленное управление данными (Кешоге 1)ага Мапаяетепг)„ ° распределенное управление данными (Р)ыг)Ьцгед Рага Мапаяешепг).
Эта условная классификации показывает, как могут быть распределены отдельные задачи между серверным и клиентскими процессами. В данной классификации отсутствует реализация удаленной бизнес-логики, так как считается, что она не может быть удалена полностью, а может быть лишь распределена между разными процессами, которые могут взаимодействовать друг с другом.
1.3. Двухуровневые модели Двухуровневые модели управления БД фактически являются результатом распределения пяти указанных ранее групп функций стандартного интерактивного приложения между двумя процессами, выполняемыми на двух платформах: компьютере клиента и на сервере. В чистом виде не существует ни одна из них, однако рассмотрим наиболее характерные особенности каждой двухуровневой модели. Модель удаленною управления данными, или модель файлового сервера (Р11е Яеггег — РБ).
В этой модели презентационная логика и бизнес-логика располагаются на клиентской части. На сервере располагаются файлы с данными и поддерживается доступ к этим файлам. Функции управления информационными ресурсами в этой модели находятся на клиентской части. Распределение функций компонентов приложения в моделях клиент — сервер представлено на рис. 1.3. В этой модели файлы базы данных хранятся на сервере, клиент обращается к серверу с файловыми командами, а механизм управления всеми информационными ресурсами — собственно база метаданных (выбранных данных) — находится на компьютере клиента.
Достоинство данной модели состоит в том, что приложение разделено на два взаимодействующих процесса. При этом сервер 16 Клиент Рис. 1.3. Модель файлового сервера (серверный процесс) может обслуживать множество клиентов, которые обращаются к нему с запросами. Собственно СУБД должна находиться в этой модели на компьютере клиента.
Алгоритм выполнения клиентского запроса сводится к следующему. 1. Запрос формулируется в командах языка манипулирования данными (ЯМД). 2. СУБД переводит этот запрос в последовательность файловых команд. 3. Каждая файловая команда вызывает перекачку блока информации на компьютер клиента, а СУБД анализирует полученную информацию, и если в полученном блоке не содержится ответ на запрос, принимается решение о перекачке следующего блока информации и т.д. 4.
Перекачка информации с сервера на клиентский компьютер производится до тех пор, пока не будет получен ответ на запрос клиента. Рассмотренная модель имеет следующие недостатки: ° высокий сетевой трафик, который связан с передачей по сети множества блоков и файлов, необходимых приложению; ° узкий спектр операций манипулирования с данными, определяемый только файловыми командами; ° отсутствие адекватных средств безопасности доступа к данным (защита только на уровне файловой системы). Клиент Рис. 1.4. Структура модели удаленного доступа к данным Модель удаленного доетуна к данным (Кеюо1е Ра1а Аеееав— КОА). В этой модели база данных хранится на сервере. Там же находится и ядро СУБД.
На компьютере клиента располагаются презентационная логика и бизнес-логика приложения. Клиент обращается к серверу с запросами на языке Я Ь. Структура модели удаленного доступа к данным приведена на рис. 1.4. Преимущества данной модели состоят в следующем: ° перенос компонента представления и прикладного компонента на клиентский компьютер существенно разгружает сервер БД, сводя к минимуму общее число выполняемых процессов в операционной системе; ° сервер БД освобождается от несвойственных ему функций, а процессор или процессоры сервера целиком загружаются операциями обработки данных запросов и транзакций; ° резко уменьшается загрузка сети, так как по ней от клиентов к серверу передаются не запросы на ввод-вывод в файловой терминологии, а запросы на языке БОЬ, объем которых существенно меньше.
В ответ же на эти запросы клиент получает только данные, соответствующие запросу, а не блоки файлов. Основным достоинством модели КОА является унификация интерфейса клиент — сервер, т.е. стандартным при общении приложения клиента и сервера становится язык $ОЬ. Недостатки данной модели: ° запросы на языке БОЬ при интенсивной работе клиентской части приложения могут существенно загрузить сеть; ° так как в этой модели на компьютере клиента располагаются и презентационная логика, и бизнес-логика приложения, при повторении аналогичных функций в других приложениях код, соответствующей бизнес-логики, должен быть повторен для каждого клиентского приложения, что вызывает излишнее их дублирование; ° так как сервер в этой модели играет пассивную роль, функции управления информационными ресурсами должны выполняться на компьютере клиента. 18 Модель сервера баз данных. Для исключения недостатков модели удаленного доступа к данным необходимо выполнение следующих условий.
1. БД в каждый момент времени должна отражать текущее состояние предметной области, которое определяется не только собственно данными, но и связями между объектами данных, т.е. данные, которые хранятся в БД, в каждый момент времени должны быть непротиворечивыми. 2. БД должна отражать некоторые правила предметной области и законы, по которым она функционирует (Вцз!пеаа Вц1еа).
Например, завод может нормально работать, только если на складе имеется достаточный (страховой) запас деталей определенной номенклатуры, а деталь может быть запущена в производство, только если на складе имеется достаточно материала для ее изготовления, и т.д.
3. Обеспечение постоянного контроля за состоянием БД, отслеживание всех изменений и адекватная реакция на них. Например, при достижении некоторым измеряемым параметром критического значения должно произойти отключение определенной аппаратуры, при уменьшении товарного запаса ниже допустимой нормы должна быть сформирована заявка конкретному поставщику на поставку соответствующего товара и т.п. 4. Возникновение некоторой ситуации в БД должно четко и оперативно влиять на ход выполнения прикладной задачи.
5. Совершенствование контроля типов данных СУБД. В настоящее время СУБД контролирует синтаксически только стандартно-допустимые типы данных, т.е, которые определены в РРЬ (Ра1а Ребпйюп Ьапяцаяе) — языке описания данных, являющемся частью ЗОЬ. Однако в реальных предметных областях существуют данные, которые несут в себе еще и семантическую составляющую, например координаты объектов или единицы измерений. Модель сервера баз данных поддерживают большинство современных СУБД: 1пГогппх, 1пягез, БуЬазе, Огас!е, МЗ ЯНЬ Яегуег. Основу данной модели составляют; механизм хранимых процедур как средство программирования ЯОЬ-сервера, механизм триггеров как механизм отслеживания текущего состояния информационного хранилища и механизм ограничений на пользовательские типы данных, который иногда называют механизмом поддержки доменной структуры.
Модель активного сервера базы данных представлена на рис. 1.5. В этой модели бизнес-логика разделена между клиентом и сервером. На сервере бизнес-логика реализована в виде хранимых процедур — специальных программных модулей, которые хранятся в БД и управляются непосредственно СУБД. Клиентское приложение обращается к серверу с командой запуска хранимой процедуры, а сервер выполняет эту процедуру и регистрирует все предус- 19 Сервер Рнс.
К5. Модель активного сервера базы данных мотренные изменения в БД. Сервер возвращает клиенту данные выполненного запроса, которые требуются клиенту либо для вывода на экран, либо для выполнения части бизнес-логики. При этом трафик обмена информацией между клиентом и сервером резко уменьшается. Централизованный контроль в модели сервера баз данных выполняется с использованием механизма триггеров, которые также являются частью БД. Термин «триггер», взятый из электроники, семантически очень точно характеризует механизм отслеживания специальных событий, связанных с состоянием БД.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
