Составители:
Рубрика:
:&:#*%)K* :(*AK & +($5(!%%)$
-%*#$A&F*:,&* ,$%+@*,:K :!+(
5@!"! 5
показано вертикальной чертой для первых трех вариантов.
Каждый вариант имеет свою область применения.
Вариант файл-сервера характерен для локальных сетей на персональных ЭВМ с небольшим чис-
лом пользов ателей. Вследствие интенсивног о трафика и трудностей с защитой информации эта струк-
тура для бо льшинств а АС малоэффек тивна. Поэтому предпо чтительнее иметь СУБ Д в узле сервера. Ва-
риант RDA — это модель удаленного узла, она наиболее распространена в насто ящее время среди АС.
В ней уменьшен трафик по сравнению с FS, унифициров ан интерфейс с СУБД на основе языка SQL.
+-0B.F690.. Клиентов в FS и RDA иногда именуют “толстыми” клиентами, так как в них сосредоточены сред-
ства выполнения приложений.
Дальнейший переход к системе распределенных вычислений приводит к перемещению приклад-
ного ПО или его части на специальный сервер или сервер БД, т.е. реализуются двух- и трехзвенные
схемы. DBS — двухзвенная структура дистанционного управления, основанная на разделении при-
кладных процедур на две части: индивидуальные для каждого пользователя и общие для многих за-
дач. В этой ст руктуре под приложением понимают совокупность именно общих процедур. Эта сово-
купность обычно представляется на процедурных расширениях SQL и сохраняется в специальном
словаре БД. В альтернативных вариантах (например, в RDA) все прикладные процедуры включаются
в прикладные программы и, следовательно, при необходимости их изменения приходится модифици-
ровать практически все прикладно е ПО. Выделение т аких процедур в отдельное приложение облег-
чает их модификацию. Кроме того, в DBS снижается трафик, так как обмены по сети происходят не
для каждой операции с БД, а для каждой транзакции, состоящей из нескольких операций.
Вариант AS реа лизуется по &"$,6($**#; +,$/$, в которой для приложений используются узлы,
отделенные от терминального (локального) узла и от сервера БД, т.е. одновременно используются мо-
дели DBS и RDA.
Помимо проблемы распределения серверных функций между узлами сети, имеется проблема
разделения этих функций между многими пользователями АС. Эта проблема решается либо по +,$/$
“#-'*-%-#-*#/7”, либо по /*#8#0#&#%#(#; +,$/$. В первой из них для каждого активного пользовате-
ля создается своя копия СУБ Д. Во второй СУБД должна быть реентерабельной программой, обслужи-
вающей одновременно многих пользователей.
!0-.DD.7-
<:DF01. ,.89.81 XO.
Особенности СУБ Д в таких сложных системах, как САПР, оп-
ределяют их квалификацию, как '*&$44$%&7)45*., (их еще называют СУБ Д третьего поколения). К
числу признаков интеллектуальной СУБД (дополнительно к охарактеризованным выше) относятся
реализация в СУБД части прикладных процедур, что характерно для структуры DBS, #0#($A$*'$
пользователей (прикладных программ) об интересующих их изменениях состояния БД, +'*,"#*'6)-
='9 +#2.&'; в БД, способность обслуживать прикладные программы, первоначально ориентирован-
ные на разные типы СУБД (назовем это свойство /*#8#0"#&#%#45*#+&5<).
Оповещение заключается в информировании программы K о совершении события, вызванного
программой I и влияющего на работу программы K (рис. 5.4). Примером события может быть выход
значения некоторого параметра в БД за допустимые пределы. Наиболее просто информирование мож-
но организовать периодическим опросом состояния БД со стороны K. Однако это усложняет ПО и не
эффективно по затратам времени и загрузке сети. Лучше возложить функцию оповещения на СУБ Д,
что и присуще интеллектуальным СУБ Д. Но для этого нужно иметь обратные ссылки на программы,
обращающиеся к БД, 0")('4) (иначе называемые &"'88$")/и), фиксирующие наступления событий,
и процедуры обработки событий (см. рис. 5.4). Удобный вариант оповещения — информирование
программы K о происшедших событиях во время ее активизации.
Для реализации многопротоколь-
ности разрабатывают специальные тех-
нологии. Наиболее известной среди
них является технология ODBC (Open
Data Base Connection) фирмы Microsoft.
Фактически ODBC представляет собой
библиотеку функций для обращений
&.+.)$(*),$". !"#$%!#&'&($"!))$* +($*,#&($"!)&*
137
%+, 5.4. Схема оповещения
5@!"! 5 :&:#*%)K* :(*AK & +($5(!%%)$-%*#$A&F*:,&* ,$%+@*,:K :!+(
показано вертикальной чертой для первых трех вариантов.
Каждый вариант имеет свою область применения.
Вариант файл-сервера характерен для локальных сетей на персональных ЭВМ с небольшим чис-
лом пользователей. Вследствие интенсивного трафика и трудностей с защитой информации эта струк-
тура для большинства АС малоэффективна. Поэтому предпочтительнее иметь СУБД в узле сервера. Ва-
риант RDA — это модель удаленного узла, она наиболее распространена в настоящее время среди АС.
В ней уменьшен трафик по сравнению с FS, унифицирован интерфейс с СУБД на основе языка SQL.
+ - 0 B .F 6 9 0 . . Клиентов в FS и RDA иногда именуют “толстыми” клиентами, так как в них сосредоточены сред-
ства выполнения приложений.
Дальнейший переход к системе распределенных вычислений приводит к перемещению приклад-
ного ПО или его части на специальный сервер или сервер БД, т.е. реализуются двух- и трехзвенные
схемы. DBS — двухзвенная структура дистанционного управления, основанная на разделении при-
кладных процедур на две части: индивидуальные для каждого пользователя и общие для многих за-
дач. В этой структуре под приложением понимают совокупность именно общих процедур. Эта сово-
купность обычно представляется на процедурных расширениях SQL и сохраняется в специальном
словаре БД. В альтернативных вариантах (например, в RDA) все прикладные процедуры включаются
в прикладные программы и, следовательно, при необходимости их изменения приходится модифици-
ровать практически все прикладное ПО. Выделение таких процедур в отдельное приложение облег-
чает их модификацию. Кроме того, в DBS снижается трафик, так как обмены по сети происходят не
для каждой операции с БД, а для каждой транзакции, состоящей из нескольких операций.
Вариант AS реализуется по &"$,6($**#; +,$/$, в которой для приложений используются узлы,
отделенные от терминального (локального) узла и от сервера БД, т.е. одновременно используются мо-
дели DBS и RDA.
Помимо проблемы распределения серверных функций между узлами сети, имеется проблема
разделения этих функций между многими пользователями АС. Эта проблема решается либо по +,$/$
“#-'*-%-#-*#/7”, либо по /*#8#0#%#(#; +,$/$. В первой из них для каждого активного пользовате-
ля создается своя копия СУБД. Во второй СУБД должна быть реентерабельной программой, обслужи-
вающей одновременно многих пользователей.
!0-.DD.7-<:DF01. ,.89.81 XO. Особенности СУБД в таких сложных системах, как САПР, оп-
ределяют их квалификацию, как '*&$44$%&7)45*., (их еще называют СУБД третьего поколения). К
числу признаков интеллектуальной СУБД (дополнительно к охарактеризованным выше) относятся
реализация в СУБД части прикладных процедур, что характерно для структуры DBS, #0#($A$*'$
пользователей (прикладных программ) об интересующих их изменениях состояния БД, +'*,"#*'6)-
='9 +#2.&'; в БД, способность обслуживать прикладные программы, первоначально ориентирован-
ные на разные типы СУБД (назовем это свойство /*#8#0"#%#45*#+&5<).
Оповещение заключается в информировании программы K о совершении события, вызванного
программой I и влияющего на работу программы K (рис. 5.4). Примером события может быть выход
значения некоторого параметра в БД за допустимые пределы. Наиболее просто информирование мож-
но организовать периодическим опросом состояния БД со стороны K. Однако это усложняет ПО и не
эффективно по затратам времени и загрузке сети. Лучше возложить функцию оповещения на СУБД,
что и присуще интеллектуальным СУБД. Но для этого нужно иметь обратные ссылки на программы,
обращающиеся к БД, 0")('4) (иначе называемые &"'88$")/и), фиксирующие наступления событий,
и процедуры обработки событий (см. рис. 5.4). Удобный вариант оповещения — информирование
программы K о происшедших событиях во время ее активизации.
Для реализации многопротоколь-
ности разрабатывают специальные тех-
нологии. Наиболее известной среди
них является технология ODBC (Open
Data Base Connection) фирмы Microsoft.
Фактически ODBC представляет собой
библиотеку функций для обращений
%+, 5.4. Схема оповещения
&.+.)$(*),$" . !"#$%!#&'&($"!))$* +($*,#&($"!)&* 137
Страницы
- « первая
- ‹ предыдущая
- …
- 135
- 136
- 137
- 138
- 139
- …
- следующая ›
- последняя »
